Meer info over volgende versies Visual Studio

Microsoft heeft afgelopen woensdag in New York een korte presentatie gehouden over de twee volgende versies van Visual Studio, namelijk de Whidbey-release eind 2004 en de Orcas-release in 2005. Visual Studio Orcas zal gebruikmaken van de nieuwe features die Windows Longhorn omstreeks diezelfde tijd ten toon zal gaan spreiden. Hierbij moet gedacht worden aan de vernieuwde user interface, het aangepaste veiligheidsmodel, trustworthy computing, de verbeterde samenwerking van de verschillende onderdelen binnen Windows, een nieuw applicatiemodel en een aantal verbeteringen op het gebied van multimedia. Orcas gaat een grote update worden. Dit in tegenstelling tot Visual Studio 2003 en Whidbey, die vooral kleinere verbeteringen bevatten. Volgend jaar zal, met de introductie van Whidbey, ook een nieuwe versie van het .NET Framework gepresenteerd worden.

Als één van de voornaamste verbeteringen zal in Whidbey de Edit & Continue-feature aanwezig zijn. Hiermee is het mogelijk om code tijdens het debuggen aan te passen, en de applicatie direct door te laten gaan op het punt waar deze gebleven was voordat de debugger ingreep. Om het ontwikkelaars makkelijker te maken heeft Microsoft een aantal nieuwe 'My'-classes toegevoegd. Deze classes kunnen gebruikt worden om specifieke hardware of Windows-instellingen aan te spreken. De functionaliteit van deze classes is al aanwezig in het .NET Framework, maar door de classes is het eenvoudiger geworden de functies ook te gebruiken. Aan de IntelliSense-features is een soort spellingscontrole toegevoegd om foutief gespelde functie- of classnamen te verbeteren. Naast deze 'grote' aanpassingen zijn er nog een heel aantal kleinere verbeteringen doorgevoerd. Opvallende nieuwigheid is de mogelijkheid om direct te kunnen communiceren met de Visual Studio-community:

Microsoft is also working to foster more of a sense of community with Visual Studio; in the Whidbey release, developers will be able to query other developers for code snippets directly from within the interface, using a new tool called Community Help. The idea, Bixhorn said, was to help developers write less code and better take advantage of the wide range of pre-written code modules available around the world. Community Help basically ties into Microsoft's developer-oriented USENET newsgroup system, he said.

Reacties (36)

[pling]

Ze zouden zich eens met de simpele dingen moeten bezighouden:

1. Hernoemen van variabelen, op een iets slimmere manier dan search and replace.
2. Automatisch toevoegen van try catch block.
3. genereren van properties op basis van member variabelen.
4. Hernoemen van classen, op een iets slimmere manier dan search replace (direct ook filenaam aanpassen).
5. Fouten weergeven tijdens het tikken of tijdens het saven, niet pas tijdens het compileren.
6. Helpen met het overriden, implementeren van methods van de base class / interface.
7. Uitlijnen van code op aanvraag (of zit dat er al in).
8. Automatisch aandragen van 'using' statements
9. Genereren van typed collectie's.
10. Add-in model kan simpeler (stuur COM is de laan uit ofzo...)

Deze opsomming zou mijn productiviteit zeker opkrikken.

Eclipse (java) (www.eclipse.org) is wat dit betreft microsoft tussen de 1 en 3 jaar voor schat ik zo.

[Verwijderd]

1. Lijkt me redelijk goed te doen via een addin
2. Zit al in VS 2003
3. Daar heb ik nu een addin voor, die op de msdn site als voorbeeld addin werd aangeboden
4. Direct bestandsnaam aanpassen aan de naam van een class is niet handig. Ik heb wel eens meerdere classes in een bestand staan
5. Dat doet intellisense redelijk tot goed, en zeker in 2003 (veeel snellere intellisense). En ze geven ook aan dat ze dat gaan verbeteren in de komende versies. Met een soort van spellingchecker zoals in word.
6. Doet ie ook al in 2003
7. Zit er ook al in
8. ???
9. Als je op de MSDN site kijkt komen wordt er iets gedaan aan het bouwen van iterator patterns. Je kunt dan voor een class aangeven dat je er een iterator voor wil gebruiken (hoe flexibel is nog maar de vraag).
10. Hmmm vond ik redelijk simpel, maar kan aan mij liggen.

Ik zal eens wat over dat Eclipse gaan lezen. Meantime, check dit artikel op msdn, is wat uitgebreider, and straight from the horses mouth. http://msdn.microsoft.com/vstudio/productinfo/roadmap.aspx

[pling]

Zou je van de zaken waarvan je aangeeft dat ze reeds in Visual Studio 2003 zitten aan kunnen geven waar deze features verborgen zitten?

Verder:

4. Direct bestandsnaam aanpassen aan de naam van een class is niet handig. Ik heb wel eens meerdere classes in een bestand staan.

Leuk als je alleen werkt maar in een team niet zo handig. classe naam en file naam 1-1 houden is mijn advies.

8. ???

using --> de namespaces die je gebruikt.

10. Hmmm vond ik redelijk simpel, maar kan aan mij liggen

Bij Eclipse heb je een plugin directory, daar zet je, je plugin in. En na een opstart zit ie er gewoon in. Geen geregistreer, geen extra registry settings, dik simpele deployment. Visual Studio gebruikt gewoon niet de mooie features van hun eigen nieuwe talen. Dat Visual Studio zo vol zit met COM is niet echt het visite kaartje van .Net.

[cannibal]

Vooral punt 6 is vanaf versie 7.1 (vs 2003) een stuk verbeterd, interfaces kunnen automatisch worden geimplementeerd (basiscode dan ) en na het typen van override in een afgeleide class krijg je alle mogelijk te overriden methods en wordt de volledige methode neergezet, zodat je meteen alle juiste parameters hebt en return type.

[rept]

Als één van de voornaamste verbeteringen zal in Whidbey de Edit & Continue-feature aanwezig zijn. Hiermee is het mogelijk om code tijdens het debuggen aan te passen, en de applicatie direct door te laten gaan op het punt waar deze gebleven was voordat de debugger ingreep.

Dit is voor de ontwikkelaars wel een toffe feature die ongetwijfeld wat tijd uitspaart. Volgens mij was dit niet super moeilijk te implementeren. De executables die VS afleverd worden niet echt meer uitgevoerd maar meer interpreted. Dat verklaart tevens de enorme frame-set die je nodig hebt om een applicatie ervan te draaien en ook de uitvoersnelheid (zeer traag).
Als je dit vergelijkt met de executables die bijvoorbeeld delphi afleverd: deze werken zeer snel en hebben geen enkele library nodig om te draaien. Maar hier zal je ook niet een feature zien om nog snel code aan te passen terwijl programma al loopt.

[cablepokerface]

Dat verklaart tevens de enorme frame-set die je nodig hebt om een applicatie ervan te draaien en ook de uitvoersnelheid (zeer traag).

Nu ben je alles behalve volledig. IL (Intermediate Language) wordt 1x (!) interpred tijdens het opstarten van de app waarna het gewoon machinetaal wordt (specifiek voor het te draaien platform). Je kunt zelfs gewoon gelijk naar machinetaal compileren als je zeker weet dat het maar op 1 platform gedraaid wordt.

[rept]

Akkoord, maar feit blijft dat de executables die VS afleverd traag zijn!

Op deze site wordt een objectieve vergelijking gemaakt tussen verschillende talen door zeer eenvoudige algoritmes: http://dada.perl.it/shootout/craps.html Vergelijk C# maar eens met Delphi en trek je conclusies. Ik heb ook zelf enkele testjes gedaan en VS haalt het zeker niet op gebied van snelheid!

[IJsbeer]

Ik vind die link van je maar een vage site. Daarin staat namenlijk ook dat Java even snel zou zijn als een C#-executable. Java staat nu niet echt bekend om zijn snelheid...

C# is echt wel een stuk sneller dan Java.. dus helemaal kloppen...

[PommeFritz]

Kom zelf eens met getallen dan, ijsbeer. Onderschat Java 1.4's hotspot JIT niet.

[VisionMaster]

[offtopic]
Alles wat met visualisatie te maken heeft vind ik rete traag in Java, maar een rekenslag in java is weer erg snel.

[ontopic]
Die features van VS spreken mij wel enorm aan. Zo'n halverwege een run veranderingen maken aan de code lijkt me een enorme winstgevende feature.

Ik vind wel dat microsoft met VS met .Net dat ze niet moeten doen als of ze het wiel (mbt de intermediat language) hebben uitgevonden.

[cablepokerface]

Op deze site wordt een objectieve vergelijking gemaakt tussen verschillende talen door zeer eenvoudige algoritmes: http://dada.perl.it/shootout/craps.html Vergelijk C# maar eens met Delphi en trek je conclusies. Ik heb ook zelf enkele testjes gedaan en VS haalt het zeker niet op gebied van snelheid!

Hahaha ... Delphi haalt een performance score van 553 en C# van 573 ... je hebt niet helemaal goed gelezen denk ik ...

[rept]

Ik denk dat jij niet goed gelezen hebt.

Deze score komt omdat er veel testen missing zijn. Bekijk de average score maar eens!!! En klik ook eens op de taal om de rankings te bekijken.
Je gaat me nu toch niet vertellen dat je echt denkt dat C# sneller is dan Delphi????

[rept]

Ik vind die link van je maar een vage site.

Ok de site ziet er niet echt uit, maar daarom is het nog geen vage site. Dit is tenminste een site waar veel informatie te vinden is, liever dat dan flashy dingen zonder inhoud. Al de code die gebruikt is staat erbij dus je kan zelf testen! Heb ik ook gedaan en bij mij kwam het mooi overeen. Je kan ook per onderdeel zien waar goed/slecht is op gescoord.

[MisterBlue]

Tot en met verise 6 was de edit & continue feature al aanwezig in de vb omgeving.
Ik heb het incidenteel toegepast, maar ik vind toch dat het slecht coderen in de hand werkt. Je moet de status van de statische code in je hoofd hebbben, maar ook de status van het draaiende programma (waarden van variabelen e.d.). Dit wil je niet als iemand ook nog in je nek zit te hijgen om te vragen of het al af is.
Ik werk liever met automatische testen om de code heen, die je in een paar seconden kunt draaien. Ik hoef dan niet de code aan te passen tijdens het draaien, maar wacht tot de test afgelopen is en pas het dan aan waarna ik de test weer draai. Werkt net zo snel en levert minder stress op dan edit & continue.
Wat ik wel vaak doe is vanuit debug mode snel even een stukje code testen zonder het te compileren. Ben wel blij dat dat terug komt.

[aphx]

Hot Code Swap bestaat al een tijdje in Java. Erg handig. Dat zegt gelijk weer iets over mijn programmeerkwaliteiten

[yeep]

De executables die VS afleverd worden niet echt meer uitgevoerd maar meer interpreted. Dat verklaart tevens de enorme frame-set die je nodig hebt om een applicatie ervan te draaien en ook de uitvoersnelheid (zeer traag)

Edit & Continue is ook beschikbaar voor standaard C/C++, dus zonder .NET framework. En dat wordt echt niet interpreted.
Ik ben eigelijk wel benieuwd wat precies voor een verbeteringen ze gaan toevoegen hiervoor.

[cablepokerface]

Ari Bixhorn, the Lead Product Manager of Visual Studio, provided a short demonstration of Whidbey Beta 1, which was also released this week to testers. Bixhorn showed off new features in the environment, such as a new window docking system, new drag and drop development features, and new Smart Tags which can, among other things, make it easier to attach data back-ends like SQL Server to code.

Vaag, vaag ... een beetje frustrerend weer dat ze niet duidelijk kunnen zijn over het maken van stored procedures in C# code in Yukon. Nou eindelijk de feature waar iedere coder op zit te wachten die ontwikkelt in VS.NET en een back-end in MS SQL Server heeft en na de eenmalige aankondiging geen concreet woord meer over gezegd.

Een tweede bezwaar is (wederom) de versie opvolging. Een ontwikkelpakket is niet iets dat een jaarlijks nieuwe versie moet krijgen. Waarom stoppen ze die dingen niet in een SP?? Natuurlijk is de kans groter dat mensen een product wantrouwen dat zo uiteenlopend is als VS.NET maar ze er ieder jaar een nieuwe doos van moeten kopen ... (mits ze willen bijblijven en geen peperduur MSDN contract hebben)

[Verwijderd]

Het hele probleem aan .Net is dat er geen goede koppeling is te maken van een objecten model naar een relationeel database model. Ik zie een database niet meer als een data-storage, een commodity. Niks speciaals dus, het moet gewoon slim mijn business objecten opslaan. Ik wil na een week of 2 niet meer omkijken naar mijn datalaag. Dat ontbreekt dus aan .Net, en er zijn al allerlei third-party producten voor, maar ik heb liever een standaard die door liefst Microsoft gesupport wordt.

[Crazy D]

SP's schrijven in C# is dan ook geen VS.net feature, maar eentje van de volgende MSSQL server. Zie http://www.itwriting.com/sqlyukon.php voor een interview met Euan Garden (Product Unit Manager voor SQL Server Tools).

[Kama]

Een tweede bezwaar is (wederom) de versie opvolging. Een ontwikkelpakket is niet iets dat een jaarlijks nieuwe versie moet krijgen.

Snel opvolgende versies heeft ook nooit iemand tegengehouden om JBuilder te gebruiken... En die zit inmiddels al op versie 9. Je bent niet _verplicht_ te upgraden...

[SoLiS]

Niet iedere VS.NET ontwikkelaar zit te wachten op C# in MS SQL Server. T-SQL statements zijn (meestal) cursorless en vele malen sneller om data op te halen en te bewerken vanuit een relationele database. Op het moment dat je die C# code in je datalaag gaat gebruiken lever je die snelheid in en ben je vaak bewerkingen aan het doen die naar mijn mening meer in een business-laag thuishoren dan in een datalaag.

Nog betere integratie tussen de datalaag en de businesslaag zou daarentegen niet gek zijn. Misschien wat tools om eenvoudig objecten te maken van tabellen uit SQL Server zou voor mij een welkome feature zijn.

[Verwijderd]

Zouden ze hun C++ ook ooit nog eens standaard-compliant maken? VC5 was een ramp, VC6 kon ook nog niet eens de STL aan en zelfs VC7 (beloofd om de grootste problemen aan te pakken) kan nog niet de hele STL aan. VC7.1 lost iets meer op maar kan weer geen PTS waardoor het boeiendste spul uit Boost en andere bekende C++ libraries niet werkt, enzovoort, enzovoort.
Laat die jongens van MicroSoft eerst eens leren hoe ze een compiler maken voor een standaard taal alvorens ze een eigen taal gaan verzinnen, of zou dat wellicht te reden voor C# zijn?

p.s. Hebben ze in VC7 nou een collapsing editor; eentje waarbij je functie-/class-/loop-/etc.-inhoud in kan klappen? Dacht zoiets te zien op schermfoto's maar hoor er verder weinig over, zou écht een handige functie zijjn; heb een bloedhekel aan grote lappen sourcecode maar soms moet het en dan zou het fijn zijn om lange stukken reeds werkende code op zo'n manier te "op te bergen".

[beany]

p.s. Hebben ze in VC7 nou een collapsing editor; eentje waarbij je functie-/class-/loop-/etc.-inhoud in kan klappen?

Visual Studio 2002: Nee
Visual Studio 2003: Ja

De ellende is: je sluit je project, je opent hem weer en hij is vergeten welke lappen code ingeklapt was en welke niet Erg irritant vindt ik...

[Verwijderd]

De ellende is: je sluit je project, je opent hem weer en hij is vergeten welke lappen code ingeklapt was en welke niet Erg irritant vindt ik...

Gebruik Kdevelop (KDE only ). De laatste testversies van 3.0 kunnen het wel

[Verwijderd]

Ja, ze hebben een collapsing editor.

En BOOST werkt gewoon. VC7.1 heeft een 100% score op de regression test. Geen enkele andere compiler heeft zo'n hoge score. Zelfs GCC en Intel niet.

Kijk zelf maar: http://boost.sourceforge.net/regression-logs/

Dus ik weet niet waar je de onzin vandaan haalt dat BOOST niet werkt enzo, maar zeker niet van BOOST zelf dus.

[Verwijderd]

Ik volg Boost al sinds jaren en ben er actief bij betrokken geweest. Zelf heb ik VC niet dus heb de legendarische bagger van alles vóór 7.0 niet meegemaakt. De logs tonen trouwens dat de vórige versie van Boost 100% was, de huidige versie, met bijvoorbeeld de metaprogramming lib en Spirit (waarin ik actief ben geweest), scoren op VC7.1 ook niet 100%. Als je trouwens de developers mailing lijst eens door leest zul je zelf zien dat er veel, véél gekunsteld wordt om VC draaiend te krijgen.

De laatste info die ik heb zegt dat ook 7.1 nog geen partial template specialization kent, een techniek die steeds vaker gebruikt wordt. Probleem is dus niet zozeer dat ze zowat alles goed doen, probleem is dat de dingen die ze niet goed doen juist heel belangrijk zijn.

Ik weet dat MS momenteel hard bezig is VC standaard-compliant te krijgen; ze hadden voor versie 7.0 in ieder geval 'n kopstuk uit C++-land aangenomen en ik weet dat er een iemand fulltime bezig is om de grote 3rd party libraries draaiend te krijgen, wat dat betrefd zijn ze van hun oude officiële standpunt ("We gaan VC nooit C++ compliant maken omwille van backwards compatibility") afgestapt, een goed vooruitzicht maar ze zijn er nog niet helemaal.

[yeep]

p.s. Hebben ze in VC7 nou een collapsing editor; eentje waarbij je functie-/class-/loop-/etc.-inhoud in kan klappen?

Ja, dat heet Outlining. Ik vond persoonlijk dat ik iets te weinig controle over het inklappen had. Als je iets inklapt dan doet ie dat namelijk vanaf de eerste regel die niet meer bij het vorige blok hoort tot en met de laatste regel van het huidige blok, met als gevolg dat je ook meteen alle witregels, die ik tussen functies plaats voor de duidelijkheid, kwijt bent.

[Verwijderd]

Wat ik op prijs zou stellen is dat de performance van het geheel eens goed verbeterd wordt. Soms krijg je gewoon heimwee naar VB6 + ASP, als het gaat om de "coden, compilen, debuggen"-cyclus.(en ik heb het hier dus niet over kleine 2-3 tier web projecten). Verder vindt ik het nog steeds heel erg dubieus dat er geen echte performance cijfers gepubliceerd mogen worden van .Net applicaties. Begrijp me niet verkeerd, .Net is een hele grote sprong vooruit qua ontwikkelplatform, maar performance?

[cablepokerface]

Begrijp me niet verkeerd, .Net is een hele grote sprong vooruit qua ontwikkelplatform, maar performance?

De performance is alles behalve ... veel sneller dan een JAVA applicatie ooit gemaakt kan worden. Zelfs de VB.NET appz verslaan (in acht genomen dat de programmeerstructuren overeenkomen) met vrij gemak die van JAVA.

Daar staat natuurlijk tegenover dat C# en VB.NET zich nog maar moeten bewijzen op een ander platform, iets wat JAVA allang heeft gedaan.

[Verwijderd]

Ik vergelijk het niet met Java, maar met bijvoorbeeld VB6 (Com) + Asp web applicaties. Microsoft heeft ontzettend veel energie in VS.Net ontwikkeling gestoken, en de ontwikkelaar daarmee als het ware verwend. Maar als je echt performance uit .Net wil halen moet je veel standaard dingen uit VS.Net vergeten, ik noem een datagrid, viewstate, overmatig gebruik van de datasets. Zoieso is MS zelf nog zoekende naar de best-practices van .Net.

[Verwijderd]

Nou.. euh, de .NET zooi hiero is stukken sneller dan onze ouwe VB6 zooi.

Dus... 't hangt er maar even van af wat je er mee doet denk ik.

[sanderv]

voornaamste verbeteringen ... de Edit & Continue-feature

Doe ik dat niet al jaren met Visual Studio 6?

(Jaja, het zal hier wel om C# en zo gaan, maar ik ben "opgegroeid" met E&C; wist niet dat er ook nog mensen waren die het zónder deden )

[_Thanatos_]

Ben benieuwd of in de volgende versie dan eindelijke die serieuze HTML-bugs eruit zijn. Die bugs weerhouden mij er echt van om het te gebruiken.

Als je nml alle auto-format rommel uitzet, dan nog vernaggelt ie je *hele* html file naar zijn eigen inzicht, waardoor het alles behalve overzichtelijk wordt, en vooral invalid. En dit gebeurt dus als je in de HTML code iets verandert en naar de designer springt (en daar ontkom je niet aan, omdat je declaraties van je componenten wilt). Spring weer terug (zonder iets veranderd te hebben en voilá

Het is al tig keer tegen MS-personeel geroepen en iedereen hoopte dat in VS.NET 2003 deze irritatie weg zou zijn. We kunnen hetzelfde hopen voor 2004, maar ik hou m'n hart vast...

[klokop]

Ik MOET versie 6.0 gebruiken op m'n werk. Ik werk er nu een jaar mee, voornamelijk voor het aanpassen van HTML, JavaScript en zo nu en dan wat ASP (vbscript). Conclusie: een van de meeste belabberde pakketten die ik ken. Het programma denk veel dingen beter te weten dan jij zelf en past die dan voor je aan, een feature die niet uit te schakelen is. Verder bestaat een simpel iets als 'word wrap' niet. Hoezo niet?? Als je een map hernoemt, past 'ie alle linkjes in je map aan naar de nieuwe situatie ('link repair'); dit kan je wel uitschakelen trouwens, maar moet je zelf voor elk project opnieuw doen, staat default op 'ja'. Enz, enz. Bah.

[Verwijderd]

Snel opvolgende versies heeft ook nooit iemand tegengehouden om JBuilder te gebruiken... En die zit inmiddels al op versie 9. Je bent niet _verplicht_ te upgraden..

Ware het niet dat bijvoorbeeld versie 2002 standaard werkt met een oud framework...

1 van de problemen die je hierdoor tegenkomt is bijvoorbeeld dat sommige toepassingen niet meer werken met het nieuwe framework( remoting)...

Dus niet je klanten upgraden!!!

[Verwijderd]

he he gelukkig maar kan ik eindelijk me msn trojan 6.0 af maken . maar moet wel lang wachten