[Alg] Irritante VS.NET

[Soultaker]

EfBe schreef op 17 december 2002 @ 22:45:
Hmm, daar heb je inderdaad gelijk in, ik dacht dat wellicht bij jou deze dingen niet disabled waren. Ik heb in ieder geval geen problemen met context-sensitive menus in visual studio.net. Ik heb ze verder in windows xp en in office xp disabled, weet niet of jij dat ook hebt, en indien nee, of dat van invloed is...

In het Windows 2000 startmenu en de Office XP menu's heb ik uitgezet, dat 'ie items naar gelang mijn gebruik gaat weglaten. Dat is hier echter niet het geval: delen van de menu's zijn voorgeprogrammeerd, zo, dat ze alleen in bepaalde contexten voorkomen. (Je kunt ze dus niet 'altijd' krijgen door ze vaker te gebruiken ofzo.) Dat zijn twee verschillende fenomenen.

Het eerste fenomeen is ontzettend irritant en als dat er in had gezeten, had ik het hele .NET gebeuren gelijk weer verwijderd. De context-afhankelijke menu's zijn hooguit lastig, maar ik ben ze toch liever kwijt dan rijk. Ik vind de werking in Visual Studio 6, waarin items die niet beschikbaar zijn disabled (grijs) weergegeven worden, veel beter, aangezien je dan niet eindeloos blijft zoeken naar een optie die wel bestaat, maar niet zichtbaar is.

[EfBe]

Soultaker: ooooh! dan heb ik het verkeerd begrepen. De menu's passen zich inderdaad aan aan wat je kunt doen. Op zich vind ik dat wel nuttig, want dan hoef je niet door lappen opties te zoeken wat je wilt hebben. Stel nou dat de greyed out opties wel zichtbaar zouden zijn (bij mij zijn overigens soms wel greyed out opties zichtbaar), dan heb je er toch nog steeds niets aan, want je kunt ze niet gebruiken , of gaat het om het idee "het zit er in, dus het kan"? . Ik kijk altijd bij keyboard setup of een optie erin zit. Veelal heb je dan ook meteen een handige shortcut te pakken.

[whoami]

Ik heb hier nog een paar eigenaardigheden in VS.NET. (Niet VS.NET 2003, maar 2002 - of hoe die 'oude' versie ook mag heten).

Vandaag was ik in C# aan het devven. Ik was bezig met een WinForms-applicatie, en plots gebeurde er iets heel raars met m'n syntax-coloring.
Ik delete een regel, en alle regels onder de verwijderde regel hadden plots geen coloring meer; behalve de commentaarregels dan.
Ik scrollde naar boven dmv Page Up, en ook daar 'verdween' de syntax-coloring plots. Bleek dat code Insight er ook de brui aan gaf.
Ik heb eens gerebuilded en toen zag zowel de Code Insight als de syntax-coloring het weer zitten; ze waren er weer. Echter, toen ik weer een regel verwijderde, was het weer van dat.

Het afsluiten en opnieuw opstarten van VS.NET brachten soelaas voor dit.

Nu, daarstraks was ik opnieuw bezig in VS.NET. Dit keer met een ASP.NET applicatie. Ik wilde een DataSet op m'n WebForm droppen en ik krijg een 'Niet nader omschreven fout' van de MS Development Environment.
Afsluiten, opnieuw starten van VS.NET helpt niet. Hoe ik die fout krijg, weet ik bijgod niet.

Hopelijk is VS.NET 2003 een stuk beter.

[.oisyn]

Ik heb het met C++ windootjes ook vaak gehad... Dan leek het alsof een stukje geheugen uit de buffer kapot was, waardoor er op een bepaalde regel allemaal vage tekens te zien waren. Het bestand sluiten en weer openen hielp dan altijd

Ik ben het in 2003 nog niet tegen gekomen, terwijl ik daar toch zowat elke dag in zit te coden

[Verwijderd]

Ik werk er nu even me en het is enorm wennen, maar darn, wat is het toch een fijn programma!!! Zo'n investering mag ons bedrijf vaker doen

Maar ik zat me de eerste 2 weken dood aan te ergeren, maar nu ik er al een paar maanden mee werk. Prima gewoon

[.oisyn]

Vraag je bedrijf maar gelijk een investering te doen van $29 per licentie om up te graden naar 2003, want in 2002 wil je gewoon niet blijven werken imho

[Verwijderd]

whoami schreef op 12 mei 2003 @ 22:22:
Vandaag was ik in C# aan het devven. Ik was bezig met een WinForms-applicatie, en plots gebeurde er iets heel raars met m'n syntax-coloring.

Een ex-collega van mij probeerde een tijd terug in Delphi 5 een iif() functie te definieren, en IEDERE keer wanneer ze "function iif(" intikte, sloot Delphi zichzelf af, zonder enige melding. Op haar machine was 't 100% reproduceerbaar, en ze gebruikte geen IDE-enhancers als CodeRush (alleen GExperts en Konopka's Palette toevoeging).
Uiteindelijk heb ik die functie maar op mijn machine in de unit gezet, en die in de repository gezet zodat ze 'm uit kon checken.

Niet alleen de VS IDE heeft kuren...

[alienfruit]

Ach. Ze zullen we het maar niet hebben over die brakke programmeurs die heel de Borland IDE verzieken met brakke IDE implementatie waardoor heel de IDE onstabiel wordt. Overigens kan ik ook niet zeggen dat VS zo fantastisch is, dat is echt zo traag als stront van de makke beer zelfs IntelliSense van ze. Dat duurt toch altijd zoooo lang.

[Mickman]

Ik vind dat gezeik bij het installeren van VS.net al te veel. Al die klote extra componenten. Laat me nou eerst eens kennis maken met .Net zonder alles er om heen.

[whoami]

alienfruit schreef op 13 mei 2003 @ 08:05:
Ach. Ze zullen we het maar niet hebben over die brakke programmeurs die heel de Borland IDE verzieken met brakke IDE implementatie waardoor heel de IDE onstabiel wordt. Overigens kan ik ook niet zeggen dat VS zo fantastisch is, dat is echt zo traag als stront van de makke beer zelfs IntelliSense van ze. Dat duurt toch altijd zoooo lang.

Je kan zeggen wat je wilt, maar de Borland IDE's zijn toch heel wat beter als het komt op het designen (in elkaar klikken) van de GUI. Op dat punt zijn ze toch heel wat beter om te gebruiken.

De Intellisense in VS.NET vind ik anders niet traag hoor. Die in Delphi is ook wel snel. Als je trage intellisense wilt zien, moet je C++ Builder er eens bij pakken.

Mickman schreef op 13 May 2003 @ 08:12:
Ik vind dat gezeik bij het installeren van VS.net al te veel. Al die klote extra componenten. Laat me nou eerst eens kennis maken met .Net zonder alles er om heen.

Die componenten heb je nu eenmaal nodig wil je .NET uberhaupt installeren.

[ Voor 18% gewijzigd door whoami op 13-05-2003 08:46 ]

[Verwijderd]

Ik vraag me eigenlijk wel af in hoeverre de bugs genoemd over VS.NET 2002 in dit draadje genoemd, verholpen zijn in 2003.

[EfBe]

Nou de ASP.NET editor is nog net zo brak. Die vernaggelt nog steeds je formatting van de HTML.

[Verwijderd]

Wat ik nu wel een vervelende 'feature' vind, is dat hij je HTML naar eigen inzicht opnieuw opmaakt. Kan je deze feature ook ergens disablen?

[Woy]

Ja bij Tools>Options>Text Editor>HTML/XML>Format.

Maar dit werkt ook niet helemaal goed. Bij mij loopt hij nog steeds regelmatig vanalles te verzieken

[Verwijderd]

whoami schreef op 13 May 2003 @ 08:45:
Je kan zeggen wat je wilt, maar de Borland IDE's zijn toch heel wat beter als het komt op het designen (in elkaar klikken) van de GUI. Op dat punt zijn ze toch heel wat beter om te gebruiken.

De Intellisense in VS.NET vind ik anders niet traag hoor. Die in Delphi is ook wel snel. Als je trage intellisense wilt zien, moet je C++ Builder er eens bij pakken.

Ik heb net een week met JBuilder 8 moeten werken, en ik snak weer naar een MS IDE... de Borland JBuilder IDE zuigt aan ALLE kanten. MS IDE's doen tenminste wat je wilt, ipv dat gezeik van Borland die steeds doet wat je NIET wilt .

Een paar voorbeelden: intappen??? Neeeeee!! Dat doet Borland toch ff leuk voor je? No way dat je een bepaalde regel ff handmatig verder kan in/uit tappen.
Meerdere woorden selecteren door te dubbelklikken en slepen zoals de halve wereld doet?? Nee, kom op zeg! Dat doe je toch niet zo, dat zou handig zijn
Snelheid? Nee, nergens voor nodig! Java GUI's zijn toch prachtig, snel en intuitief??? NOT!
Etc. etc.

Nu zou je dit deels vast wel kunnen verbeteren in de instellingen, maar dit mogen toch nooit de default instellingen zijn!

/me heeft na 1 week werken met JBuilder er al meer dan genoeg van en kan zich niet voorstellen dat er ook maar één tevreden JBuilder developer bestaat

Niet dat ik wil zeggen dat VS.NET perfect is, zeker niet, maar het is gewoon nagenoeg onmogelijk om een dermate groot product voor een zo kritische doelgroep (devvers denken het altijd zélf beter te weten ) perfect te maken.
En persoonlijk vind ik dan dat MS's VS.NET beter in deze opdracht slaagt dan Borland's JBuilder

[LordLarry]

MicroSoft's IDE's zijn dan ook niet gemaakt in Java. Java is gewoon langzaamer vergeleken met native of zelfs .Net. Bovendien zijn de andere Java IDE's nog slechter als JBuilder, dus kan je nagaan.

[whoami]

Als ik het eerder had over de Borland IDE's , dan had ik het over Delphi en C++ Builder.
Met JBuilder heb ik nog nooit gewerkt.

Ik ben benieuwd hoe het zit met de useability van Borland's C# Builder (SideWinder). Hopelijk is die beter / gebruiksvriendelijker om een UI in elkaar te klikken dan VS.NET. Ik vind nl. dat je dat in VS.NET niet zo snel kunt doen dan in bv Delphi.

_{let op, ik zeg niet dat VS.NET een slecht pakket is. Ik zeg gewoon dat bepaalde dingen beter kunnen.}

[-Klimaks-]

LordLarry schreef op 13 May 2003 @ 11:25:
MicroSoft's IDE's zijn dan ook niet gemaakt in Java. Java is gewoon langzaamer vergeleken met native of zelfs .Net. Bovendien zijn de andere Java IDE's nog slechter als JBuilder, dus kan je nagaan.

Mmm, sinds ik met IDEA gewerkt heb, wil ik toch niet meer terug naar VS.NET. En IDEA is helemaal niet traag als Java App

offtopic:
Heb hier op mijn stage een afdeling van 25 man volledig laten overstappen van netBeans naar IDEA

[xoror]

voor curry:

veel fouten in bcb worden veroorzaakt door die k*t class explorer. die moet je eruit slopen.
ik dev ook voornamelijk in bcb , maar zonder de class explorer krijg ik bijna geen crashes van de IDE meer.

verder zet ik ook altijd die auto completion troep uit. als ik nodig heb ram ik wel op ctrl + spatie

anyway, ik geloof verder dat je nu op je knieen kan zitten, borland heeft c# builder aangekondigd helaas wel borland IDE maar wel ms C# compiler en linkers.....

[Verwijderd]

Als eerste werk ik ook met C++ Builder 6, zo traag vind ik CodeCompletion nou weer niet, maar jah. Zowel bij VS als bij CB kost het allemaal tijd, die je ook kon besteden aan typen, veel typen

whoami schreef op 13 May 2003 @ 11:37:
Als ik het eerder had over de Borland IDE's , dan had ik het over Delphi en C++ Builder.
Met JBuilder heb ik nog nooit gewerkt.

Ach, J Builder is ook lekker traag, maarja dat komt vooral door dat het in Java is gemaakt.

Ik ben benieuwd hoe het zit met de useability van Borland's C# Builder (SideWinder). Hopelijk is die beter / gebruiksvriendelijker om een UI in elkaar te klikken dan VS.NET. Ik vind nl. dat je dat in VS.NET niet zo snel kunt doen dan in bv Delphi.

Nou ik denk dus niet dat het verscheelt, als je zo naar de flash demo kijkt kun je zien dat het dezelfde form designer gebruikt als VS.Net (verwacht maar een hoop geflame hierover; zullen wel geen tijd hebben willen besteden aan een eigen designer). Omdat ze VS.Net designer zal het niet mogelijk zijn om een zwevend form designer te krijgen zoals in Delphi etc.

_{let op, ik zeg niet dat VS.NET een slecht pakket is. Ik zeg gewoon dat bepaalde dingen beter kunnen.} :)[/quote]

Alles kan altijd beter
Ik vind zoals boven al benoemd was, de benodigde windows components updates die je moet draaien om Vs.Net te kunnen draaien, behoorlijk irritant. Nu hoorde ik dat je voor C# Builder ook .NET 1.1 nodig hebt.

[ Voor 3% gewijzigd door Verwijderd op 13-05-2003 12:27 . Reden: foutje :( ]

[whoami]

Ik dacht dat C# Builder en de nieuwe Delphi dezelfde UI (form-designer) zouden gebruiken en dat je 2 verschillende 'designer'-modes zou hebben; nl. de 'klassieke' Delphi mode, en de VS.NET mode oid.

Tuurlijk heb je voor C# builder ook .NET framework nodig. Hoe zou je anders in C# of een andere .NET taal kunnen ontwikkelen zonder framework?

[Verwijderd]

Ik dacht dat C# Builder en de nieuwe Delphi dezelfde UI (form-designer) zouden gebruiken en dat je 2 verschillende 'designer'-modes zou hebben; nl. de 'klassieke' Delphi mode, en de VS.NET mode oid.

Dat heb je dan verkeerd gedacht, sorry. Maar ze gebruiken toch echt de form designer van .NET en niet een zelfgemaakt. Je kunt wel een kloon krijgen van de UI van de Delphi met zijn vliegende vensters alleen het blijft altijd een "venster in venster"-idee zoals in VS.NET. Wat ik zelf vreselijk irritant vind maar goed

Tuurlijk heb je voor C# builder ook .NET framework nodig. Hoe zou je anders in C# of een andere .NET taal kunnen ontwikkelen zonder framework?

[/quote]

Ooh. Ik bedoelde dat je versie 1.1 voor nodig schijnt te hebben, ipv. van 1.0. Ik zal het eens naar lezen.

[whoami]

Iemand bekend met volgende error in VS.NET 2002 ?

Newline in constant

Ik krijg deze error bij het compileren op een string die ik wil concateneren.
Daarnet ging het allemaal nog goed, nu komt ie met deze error op de proppen.

[D2k]

uhm lijkt erop alsof je ergens op <enter> hebt gedrukt waar het niet mag (dat zegt de error iig)

[whoami]

Dat zegt die error idd, maar voor zover ik het weet heb ik het niet gedaan.
Daarnet compilede alles nog goed.
Ik heb de code eens in TextPad geplakt, en ook daar ziet alles er goed uit.

[Woy]

Ben je niet per ongeluk vergeten ergens een string af te sluiten ofzo?

[whoami]

Nope.

Ik heb daar idd al op gechecked, maar dat is dus niet het geval.

[.oisyn]

Heb je een stukje code?
Of staat er misschien per ongeluk een \ voor je " ?

[Woy]

Heb je niks aan de regel waarop je de error krijgt? of is het ergens redelijk willekeurig in je source waar hij het aangeeft?

[whoami]

't Is opgelost.

Het had niks met code te maken hoor, ik heb de code eens verwijderd, en hij gaf die fout nog.

Ik heb uiteindelijk vs.net eens afgesloten en opnieuw opgestart, en nu compiled hij zonder problemen.

[EfBe]

is bug in 2002

[EfBe]

Trouwens de hard-linking met .NET 1.1 in vs.net 2003 is wel erg vervelend: als je een tool maakt die geen .NET 1.1 features gebruikt, maar je wilt WEL de nieuwe leuke features van VS.NET 2003 gebruiken (zoals de veel betere intellisense) dan ben je goed zuur, want je assemblies gecompileerd met VS.NET 2003 gebruiken .NET 1.1, en indien je die distribueert moet de gebruiker OOK .NET 1.1 op zn machine hebben. Als ISV heb je dus 2 keuzes: OF je kiest voor het gebruik van .NET 1.1 en je klanten moeten dat ook maar doen, OF je kiest voor .NET 1.0 en .NET 1.1 support en dan heb je veel extra werk want je moet 2 versies van DEZELFDE code supporten en compileren met 2 compilers. Voor .exe's is er nog de config file, maar voor components en libraries is dat niet mogelijk.

Ik ben nu gemigreerd naar vs.net 2003 maar zit dus nu in de ellende, want ik kan geen 1.0 targetten in de compilatie van mn framework dlls. Dat moet OF met de hand OF ik moet vs.net 2002 weer installeren MAAR dan heb ik de ellende dat de projects al geconverteerd zijn en die moet ik dan OF met vss terugrollen OF met de hand aanpassen. (En je zit met die zeer buggy IDE die nog steeds niet gepatcht is middels een service pack)

MS heeft met hun vendor locking spelletjes de laatste groep die ze nog niet hadden genaaid nu ook belazerd: de developers en ISV's. Bedankt MS!

[Verwijderd]

EfBe schreef op 20 mei 2003 @ 13:06:
Verhaaltje

Zwaar irritant, ik vind die hele overgang van 2002 naar 2003 IDE & Framework maar lastig. Ik heb nu inmiddels weer VS.net 2002 geinstalleerd om aan "oudere" projecten te kunnen werken zonder conversies en framework verschillen.

Zou een stuk makelijker kunnen zijn als je gewoon bij een project in VS 2003 kon aangeven welk framework je wilt gebruik.

[Woy]

Ik vindt het inderdaad ook heel vreemd dat dit niet kan. Ik was er al verbaasd over dat er bij vs.net 2002 een vaste locking met .net 1.0 was waardoor het nu niet mogelijk is om in .net 1.1 te werken in 2002 ( ok dat wil je ook niet maar toch ) en dus verplicht bent om over te stappen op vs.net 2003 voor .net 1.1. Maar stel nou dat ze over een tijdje de volgende versie van .net uitbrengen moet je weer een nieuwe ide kopen. Ze hadden het beter in modules op kunnen splitsen die los te koppelen zijn.

[whoami]

Nog een bug die voor ergernissen zorgt (welke bug doet dat trouwens niet):

Ik heb het nu al 2x voorgehad dat ik, in de form designer van VS.NET 2002
mijn mousepointer niet meer krijg waar ik hem hebben wil.
Het lijkt wel of m'n pointer 'gevangen' zit binnen een bepaald gebied. Als dit optreedt,
dan beperkt het zich ook niet tot VS.NET alleen. Als ik switch naar Word bv, dan doet het
probleem zich daar ook voor.

De enige oplossing is om de solution in VS.NET te sluiten.

[.oisyn]

ga je nu de hele tijd 2002 bugs posten terwijl allang bekend is dat die IDE buggy is? (2003 was er niet voor niets zo snel al). Imho een beetje nutteloos

^{en hiermee verklaar ik de devschuur mod-war voor geopend}

[ Voor 7% gewijzigd door .oisyn op 21-05-2003 10:53 ]

[whoami]

Ik spui hier gewoon de ergernissen die ik tegenkom in VS.NET 2002.
Dat 2003 minder buggy is, zal mij voorlopig een zorg wezen aangezien hier nog altijd met 2002 gewerkt wordt.

Die bugs moesten gewoon dmv een service pack opgelost worden, ipv de mensen te verplichten om naar 2003 over te stappen.

_{ow, en voor die modwar ben je te laat. Die heeft vorige week al gewoed in DC}

[ Voor 14% gewijzigd door whoami op 21-05-2003 11:13 ]

[.oisyn]

Ja maar dan wordt het dus gewoon een opsomtopic, die in principe niet toegestaan zijn

[EfBe]

kiezen voor 2003 is ook automatisch kiezen voor .NET 1.1 en de ellende van de versioning van je assemblies wanneer je klanten beide versies van .NET kunnen hebben (i.e.: meerdere versies onderhouden en dus voor elke versie een IDE installeren EN project files beheren of alles met de hand compileren).

Ik kan me ook herinneren dat MS heeft beweerd dat er snel een SP zou volgen na de release van vs.net 2003. Dat is al een maand uit, nog geen sp, zelfs geen beta. Ik heb sterk het vermoeden dat dat sp er pas komt wanneer die aanbieding van 29$ afgelopen is (waar veel mensen nog niet van kunnen profiteren want MS levert nauwelijks uit).

[Verwijderd]

EfBe, ga je naast je weblog er hier nu ook al een probleem van lopen maken??!??

Ik ben het wel met je eens hoor....

[EfBe]

Heh, nee, maar je kunt het niet genoeg benadrukken. Sommige Microsoft piepeltjes waren 'not amused' door die blog over dit onderwerp gisteren, maar ze zijn nu iig wakker.

[alienfruit]

kiezen voor 2003 is ook automatisch kiezen voor .NET 1.1 en de ellende van de versioning van je assemblies wanneer je klanten beide versies van .NET kunnen hebben (i.e.: meerdere versies onderhouden en dus voor elke versie een IDE installeren EN project files beheren of alles met de hand compileren).

Je kunt natuurlijk altijd SDK van 1.0 en 1.1 installeren, en apart compileren via een compile batch file-tje ipv. van een heel ide installeren..... Werkt prima.

[EfBe]

In een multi-project omgeving met dependencies is dat wat lastiger, en je betaalt voor een IDE omdat die commandline compiles moet voorkomen. Anders kun je net zo goed sharpdevelop downloaden en debuggen in de sdk debugger.

[Crazy D]

Ik werk sinds een aantal weken met VS.Net en ik begin teveel bugs te herkennen Nou kan ik er op zich wel mee leven, want nu heb ik een goede reden om bugs te schrijven in mijn software... maar vervelend is het toch wel. Helemaal die bugs die alleen "over" zijn als je VS ff opnieuw start.

EfBe: nice blog

[D2k]

Crazy D schreef op 21 May 2003 @ 13:18:
EfBe: nice blog

heb net ook ff het laatste artikel bekeken en de reacties erop. Nogal kansloze reacties imho zonder inhoud om echt feitelijk wat aan de gestelde zaken in het artikel te verhelpen. jammer van die zogenaamde "kenners"
</ot>

[tijn]

Verwijderd schreef op 21 mei 2003 @ 12:23:
EfBe, ga je naast je weblog er hier nu ook al een probleem van lopen maken??!??

Goeie blog man! Ik kwam er toevallig voorbij net voordat ik op het punt stond om argeloos een gloedjenieuwe 1.1 Class Library aan een 1.0 project toe te voegen. Tnx voor je rant

offtopic:
Het probleem dat veel mensen met je blog hebben komt volgens mij ook voort uit het feit dat ze proberen om MS lui te laten bloggen (zie o.a. de petitie om Scott Guthrie en Rob Howard actiever te laten worden). Je provocerende stukjes zouden wel eens afschrikwekkend kunnen werken.

[EfBe]

Dank dank

Op zich hebben die negatieve reacties wel een punt: rants trekken The Register publiek aan, en stoten serieuze mensen af. Het probleem aanstippen kan ook anders, mensen lezen blogs kennelijk niet als "Ah, spuit 11.2 heeft ook een scheet gelaten", maar "Oh kijk wat ik hier lees, dat is waar, want het staat op internet".

Ontopic:
Over die 1.1 class libs samenvoegen met 1.0 progs in vs2002, men beweert dus bij hoog en bij laag dat het wel kan zonder gepruts. Ik krijg het op de commandline echter niet voor elkaar, tijn heb jij nog vs2002 en vs2003 geinstalleerd staan? Kun jij testen of een simpele 1.1 class lib die een .net class gebruikt buiten de system namespace (dus dat hij een aparte assembly moet inladen) wel te gebruiken is in vs2002 en dat de code in vs2002 wel werkt? (Want dat moet het geval zijn zeggen 'de kenners'). Ik heb vs2002 niet meer geinstalleerd dus ik kan dat niet testen, alleen op de commandline en dat werkt dus keihard NIET.

[tijn]

EfBe schreef op 21 May 2003 @ 15:23:
Kun jij testen of een simpele 1.1 class lib die een .net class gebruikt buiten de system namespace (dus dat hij een aparte assembly moet inladen) wel te gebruiken is in vs2002 en dat de code in vs2002 wel werkt? (Want dat moet het geval zijn zeggen 'de kenners'). Ik heb vs2002 niet meer geinstalleerd dus ik kan dat niet testen, alleen op de commandline en dat werkt dus keihard NIET.

Nou, ff wat dingen getest en het gaat idd fout. Dit lukt echter niet op een systeem met zowel vs2002 als vs2003 geinstalleerd. De 1.1 library deed het daar prima binnen een webapp die gegarandeerd op 1.0 draait (mappings in IIS) om de __doPostBack() bug van 1.1 te omzeilen. Echter bij een collega die alleen vs2002 draait ging het feest niet door. Compileren lukt overigens wel gewoon.

[ Voor 16% gewijzigd door tijn op 21-05-2003 18:29 . Reden: vage onzin weggehaald ]

[EfBe]

Ik heb een oplossing gevonden hiervoor. In vs.net 2003 keihard de references van .net 1.0 assemblies toevoegen en de 1.1 references verwijderen. Project compileren -> go

Eisen: je moet alle projects in je solution voorzien van 1.0 references. Het is dan wellicht beter om de class libs die ook op 1.0 moeten worden gebruikt in een eigen solution te plaatsen.

[ Voor 37% gewijzigd door EfBe op 21-05-2003 20:45 ]

[whoami]

Waarom veranderd VS.NET de namen van mijn componenten in de ItemTemplates van mijn DataList ?

[EfBe]

Omdat ze dubbel zijn waarschijnlijk. Je alternate itemtemplate ziet hij niet als iets dat hetzelfde kan zijn. Die butt-tool (die ASP.NET editor) snapt niet wat er in zjjn editspace gebeurt.

Tezamen met de random-reformats is die bug toch wel de allerergste.

Gister kwam ik nog vreemde crap tegen in de debugger van vs.net 2003: internal member van object A is "foo". Je stept een method in. zet die member op "bar". Komt terug in de scope van de caller, member staat nog op "foo" en blijft dat. Console.WriteLine statement laat zien dat de member de waarde "bar" heeft. Hallo, debugger, als iets wijzigt dan moet je dat laten zien. mega triest. Die debugger van 2003 is niet een verbetering dat is zeker.

[whoami]

EfBe schreef op 24 May 2003 @ 11:32:
Omdat ze dubbel zijn waarschijnlijk. Je alternate itemtemplate ziet hij niet als iets dat hetzelfde kan zijn. Die butt-tool (die ASP.NET editor) snapt niet wat er in zjjn editspace gebeurt.

Neen, dat is het geval niet.
Als ik die namen echter zelf verander in de HTML view van m'n webform, dan blijven ze wel goed staan.
Verander ik ze via de Property page, dan bestaat de kans dat ze plots opnieuw veranderd zijn.

Tezamen met de random-reformats is die bug toch wel de allerergste.

Gister kwam ik nog vreemde crap tegen in de debugger van vs.net 2003: internal member van object A is "foo". Je stept een method in. zet die member op "bar". Komt terug in de scope van de caller, member staat nog op "foo" en blijft dat. Console.WriteLine statement laat zien dat de member de waarde "bar" heeft. Hallo, debugger, als iets wijzigt dan moet je dat laten zien. mega triest. Die debugger van 2003 is niet een verbetering dat is zeker.

Tja, er is idd nog heel wat werk aan de winkel.

[LoekD]

Kijk anders voor de grap hier eens naar:
http://www.microsoft.com/...s/appserver/mngfrmwk.mspx
Het fenomeen side-by-side execution is met name iets waar jullie volgens mij veel aan hebben.
In het kort:
Zoek je web.config / application.exe.config en voeg het volgende toe:
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
<supportedRuntime version="v1.0.3705" />
</startup>
</configuration>
Wanneer dit in de applicatie-configuratie file wordt meegegeven, betekent dat dat de bijbehordende applicatie zowel in .NET framework 1.1 als 1.0 kan draaien, en dat 1.1 de voorkeur geniet.

Stel dat je een applicatie maakt die in slechts 1 van de 2 kan draaien, laat dan de versie die er niet toe doet weg en de goede staan:


Bijv.: Alleen 1.1:

<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>

[alienfruit]

Harstikke bedankt!

[whoami]

ff kicken.

Waar ik me ook zo aan irriteer in VS.NET is de implementatie van die alignment - palette dingen.

Als ik een aantal controls wil uitlijnen bv mbhv die functies op die toolbar (ik wil een aantal labels bv. links uitlijnen), dan ga ik die labels allemaal selecteren en klik ik op het gepaste knopje.
Nu, wat doet VS.NET: hij neemt de Left waarde van het laatst geselecteerde label, en zet de Left waarden van alle andere geselecteerde labels op die waarde.
Nu, dat is irritant, gewoon omdat ik het logischer vind dat hij ze zou uitlijnen op die label die je eerst geselecteerd hebt, en niet andersom.

[EfBe]

Dat is toch iets wat je 1 keer fout doet?

[alienfruit]

Ik irriteer me mateloos aan dat erg geen goeie fatsoenlijke MDA/UML designer in VS.NET 2003 zit zoals in C#Builder of ik mis wat

[Verwijderd]

alienfruit schreef op 15 augustus 2003 @ 12:36:
Ik irriteer me mateloos aan dat erg geen goeie fatsoenlijke MDA/UML designer in VS.NET 2003 zit zoals in C#Builder of ik mis wat

Er zijn wel meer dingen die je graag zou willen hebben, maar die er niet in zitten refactoring support bijvoorbeeld, of deze dingen.

[whoami]

EfBe schreef op 15 August 2003 @ 12:32:
Dat is toch iets wat je 1 keer fout doet?

Een oude vos verleert z'n streken niet.
In Delphi was het andersom, vandaar....

[RetepV]

Ik vind het het ergste dat Visual Studio .NET bij mij zo'n 6 a 7 keer per dag crasht. Ik heb een app die veel threads aanmaakt, en bij het debuggen crasht de boel als mijn app stopt. Volgens mij doordat het voor VS.NET te lang duurt voordat alle threads weg zijn.

Edit:

Wat ik nog VEEEEEEEEEEL irritanter vind, trouwens, is het feit dat alles nu op IE6 gebaseerd is :(:(:(:(:(:(. Alles is 4 keer zo traag geworden.

Wel leuk om je collega's te zieken door stiekem de javascriptjes aan te passen .

[ Voor 33% gewijzigd door RetepV op 15-08-2003 13:31 ]

[alienfruit]

Same here whoami
De benaming van verschillende methodes voor het maken van een .NET Control is bijvoorbeeld ook precies andersom (als in de VCL). Maar gelukkig ben ik niet de enige zulke fouten maak, zelfs in boeken zitten zulke fouten. Waarbij iemand bijv. de werking van MouseMove wilt aanpassen, maar in het boek werken ze met de event ipv van de event dispatch method. Lekker handig

[ Voor 6% gewijzigd door alienfruit op 15-08-2003 13:38 ]

[.oisyn]

alienfruit schreef op 15 August 2003 @ 12:36:
Ik irriteer me mateloos aan dat erg geen goeie fatsoenlijke MDA/UML designer in VS.NET 2003 zit zoals in C#Builder of ik mis wat

imho hebben ze dat gewoon uitbesteed aan Rational. Kijk maar eens naar rational XDE, een vs.net add-in met ondersteuning voor roundtrip engineering (hoewel Rational tegenwoordig natuurlijk wel van IBM is...)

[ Voor 8% gewijzigd door .oisyn op 15-08-2003 15:18 ]

[mulder]

Denk dat ze misschien Visio hier voor gaan inzetten

[Woy]

Don Facundo schreef op 15 August 2003 @ 15:42:
Denk dat ze misschien Visio hier voor gaan inzetten

Dan mogen ze eerst nog wel een hele hoop verbeteringen aan visio aanbrengen. Visio is op zich best een leuk programmatje om wat schematjes te tekenen maar het heeft nog lang niet de mogelijkheden van bijvoorbeeld rational XDE

[mulder]

Nou om Visio een ' leuk programmatje om wat schematjes te tekenen' te noemen is ook niet echt aardig tov Visio. Shapes in Visio zijn eigenlijk gewoon objecten en triggeren events ed. Je zou zelf al een plugin kunnen schrijven die code genereerd aan de hand van je schema.

[Woy]

Don Facundo schreef op 15 August 2003 @ 16:02:
Nou om Visio een ' leuk programmatje om wat schematjes te tekenen' te noemen is ook niet echt aardig tov Visio. Shapes in Visio zijn eigenlijk gewoon objecten en triggeren events ed. Je zou zelf al een plugin kunnen schrijven die code genereerd aan de hand van je schema.

Je zou natuurlijk ook gewoon meteen van de al bestaande code generatie functionaliteit van visio kunnen gebruiken

Ik zeg ook niet dat visio slecht is ofzo maar het heeft gewoon nog lang niet de functionaliteiten die andere pakketen wel bieden

[alienfruit]

Agh. In Borland C#Builder Architect zit TogetherSoft en Bold klinkt als een goed alternatief, maar ja het is een versie 1 (zal dus net zo brak zijn als vs.net 2002) en Architect versie kun je nog niet kopen

[EfBe]

.oisyn schreef op 15 August 2003 @ 15:14:
[...]
imho hebben ze dat gewoon uitbesteed aan Rational. Kijk maar eens naar rational XDE, een vs.net add-in met ondersteuning voor roundtrip engineering (hoewel Rational tegenwoordig natuurlijk wel van IBM is...)

Laat ik er dit over zeggen. Het heet Whitehorse en het is heel secret en het komt in 2004 (is niet op visio gebaseerd overigens)

[ Voor 5% gewijzigd door EfBe op 15-08-2003 17:14 ]

[Woy]

EfBe schreef op 15 August 2003 @ 17:13:
[...]

Laat ik er dit over zeggen. Het heet Whitehorse en het is heel secret en het komt in 2004 (is niet op visio gebaseerd overigens)

Hier kan ( mag? ) je zeker niet meer over vertellen? Ben al even aan het zoeken of ik er meer over kan vinden.

[EfBe]

rwb schreef op 15 August 2003 @ 17:33:
[...]
Hier kan ( mag? ) je zeker niet meer over vertellen? Ben al even aan het zoeken of ik er meer over kan vinden.

Ik heb de NDA voor whitehorse niet getekend (alleen die voor Whidbey) maar het wordt een soort designer voor distributed applications. Top down designen, je maakt services aan op servers, je designed met UML de interfaces, etc. en er komt code uit. Het is nog erg prematuur allemaal, maar het is veelbelovend. Reken maar dat Rational zn .NET tak wel kan sluiten wanneer whidbey enterprise op de markt komt.

[ Voor 15% gewijzigd door EfBe op 15-08-2003 17:52 ]