1) formpje om iets toe te voegen aan de toolbox is nog steeds 320x150 pixels of zo en niet resizable en duurt NOG langer vanwege de WPF troep die er nu ook op staat.
2) de UI is verschrikkelijk: men fade nu naar een of andere highlight kleur toe in de toolbars, waardoor XP met een custom theme je steevast opzadelt met een IDE UI die zo wit is dat je een zonnebril nodig hebt
3) Het start veel sneller op
4) veel lijkt nog trager dan vs.net 2005. Heb webforms nog niet getest, maar weinig hoop.
Al met al een draak van een IDE upgrade, maar goed, MS luistert nauwelijks naar feedback, dus ik heb er bar weinig vertrouwen in dat het uberhaupt ooit beter wordt. Ik bedoel, op de laatste MVP summit zitten we daar in redmond, zegt zo'n general manager: "And, what do you think should be improved in 'perf' (performance)" ? Iemand roept: "how about not scanning for COM objects when you're adding a reference to a .NET project, but only on demand?"... "Oh that's a good one".
Pardon? Dus niemand aan de knoppen bij MS heeft ooit een reference toegevoegd aan een project en zich afgevraagd waarom het toch zo takketraag was?
Een van de vele tenenkrommende voorbeelden. Uiteraard was een jaar voordat er een release was het al te laat om nog IETS te doen aan orcas.
Ik kan gewoon zo langzamerhand niet meer tegen de onnozelheid van sommige truttige onderdelen in VS.NET waarbij je elke dag dat je er weer tegenaan loopt jezelf afvraagt of het groepje nuckelheads die het gebouwd heeft er ooit wel eens echt mee gewerkt heeft...
Ik bedoel alleen al dat toevoegen van een object aan de toolbox. Binnen MS doen sommige teams dat dus VELE MALEN per dag, om hun eigen controls te testen. Ik zou GEK worden van die postzegel dialogs die elke keer je hele systeem afkachelen op zoek naar COM objects waarin je niet in bent geinteresseerd...
Een ander onderdeel, waar ik me kapot aan erger is het gebrek aan een I/O queue in de IDE. Dit resulteert in veelvuldig steppen van de harddiskkop en dat kost intens veel tijd. Dus, ipv dat ieder proces in de IDE een request plaatst in een centrale I/O queue in de IDE (en de disk opdrachten dus sequentieel worden afgehandeld) wordt alles parallel gedaan. Maar dit resulteert in traagheid die niet te ondervangen is met meerdere CPU's, de HDD is nl. veelal de bottleneck. Toen ik opperde dat een centrale I/O queue wellicht nuttig zou zijn, kon dat niet in VS.NET want tja, er waren zoveel verschillende teams die allemaal aan vs.net werkten, en op veel plekken zaten in de VS.
Ik denk dan... communicatie? Design?
[
Voor 38% gewijzigd door
EfBe op 10-09-2007 09:23
]