Microsoft verrät erste Details zu Visual Studio "10"

Entwicklung Die nächste Version von Microsofts Entwicklungsumgebung Visual Studio nimmt langsam Form an. Bisher ist das Paket nur unter seinem internen Codenamen Visual Studio "10" bekannt. Ein Microsoft-Mitarbeiter hat nun erste Details preisgegeben. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Später! Später! Später! Ich finde zwar, dass VS seit 7 große Sprünge gemacht hat, aber sie sollten nicht die Stabilität darunter leiden lassen. Wenn da so viel neuer Kram reinkommt, dann wird es unter umständen noch verbugter. Bleibt auch zu hoffen, dass die Hilfe besser wird. Eine "kleine" Befehlsreferenz wäre auch gut. Teamarbeit ist ja mit Addons schon möglich aber wozu soll man da Chatten können? =)
 
"noch verbugter" - klingt für mich, als hättest du irgendwelche Bugs gefunden... frag mich nur gerade... welche ? Chatten für Leute, die nicht unbedingt direkt im selben Raum sitzen oder Konferenzen machen. Die ganze Multi-User-Arbeit geht ja heute schon mit dem Team Foundation Server und Team Systems
 
@pkon: Ja das frage ich mich auch gerade...
 
@cH40z-Lord: Zum einen hab ich Probleme beim Umwandeln von VS7 und VS8 Projekten zu VS9 Projekten. Einige Projekte funktionieren bei mir gar nicht, weil VS7 + 8 + 9 Probleme mit Com-Objekten hat. Ich registriere im Projekt eine DLL. Bis dahin klappt alles super. Aber wenn ich dann versuche auf die Funktionen zuzugreifen fliegt mir die DLL um die Ohren. Es kommt jedes mal die Meldung, dass versucht wird im geschützten Speicher zu schreiben. Und bei jedem 3. Mal stürzt VS9 und VS8 beim selben Projekt ohne Fehlermeldung ab. Es gibt keine Meldung von Windows, dass VS abgestürzt ist oder nicht mehr reagiert. Es stürzt einfach ohne jeglichen Hinweis ab. Wenn ich dann per Breakpoints durchgehe, ist das genau an der Stelle, wo sonst das Problem mit dem Geschützten Speicher auftritt. Dann hab ich noch das Problem, dass VS9 und VS8 freezed, wenn man auf Prozesse zugreift und die nicht schnell genug antworten. Noch ein kleiner Bug ist, wenn ich ein Projekt starte, dass die Anwendung zu sehen ist, aber nicht in der Taskleiste auftaucht. Wer noch mehr hören will, der soll mich anschreiben. =)
 
@tipsybroom: Hmm, also bei uns gibt es keine solche Probleme. Vielleicht gab es einen Patch oder so? Zumidnest bei uns wird alles immer brav upgedatet, vielleicht hast du da was vergessen. Frag mich aber nicht, wo es was gibt, ich kümmer mich um andere Dinge. Oder etwas falsch konfiguriert.. wie gesagt, bei uns läuft alles bestens :) Auch die Konvertierung zwischen VS9<->VS8 klappt problemlos. Manchmal muss man jedoch von Hand in den Datien die Version ändern (vorallem, wenn man von 9 auf 8 geht, z.B. Solutions, Einstellungen-Export, etc.), aber dann klappt es auch. Oder du hast irgendeine veraltete Version oder whatever...
 
@NewsLeser: Ich weiß auch nicht, woran es liegt. Mein System ist "frisch" und hat auch alle SPs und Updates. Das kürzlich veröffentlichte Update für VS9 habe ich auch eingespielt. Seit dem ist komischerweise Intellisense in englisch obwohl der Rest in deutsch ist. Was die Abwärtskompatibilität angeht, hab ich mir ein kleines Tool zum Verwalten der Solutions geschrieben. Es nervt wirklich die sln-Dateien anzupassen. Gruß Tipsy
 
*knirsch* wissen die nicht dass Entwickler kein Klicki-bunti wollen?
 
@Samin: Frischer Wind und Windows Presentation Foundation bedeutet nicht, dass etwas Klicki-Bunti wird. Es kann auch bedeuten, dass neue, praktische Features reinkommen, ohne dass es auf den ersten Blick sichtbar wird.
 
@Samin: Mh WPF bringt aber bekanntermaßen nur Klickibunti-Vorteile. Zurzeit ist die Performance auch deutlich schlechter als nativ/GDI/WinForms. Man kann nur hoffen dass daran noch ordentlich geschraubt wird, ansonsten wirds eher eine Qual.
 
@Samin: Wer sagt denn dass Entwickler keine neue moderne Oberfläche haben wollen? warum soll alles verstaubt aussehen? Ist doch schön wenn alles optisch ansprechender ist, so eine Software nutze ich gerne. Von Applikationen mit "Win95-Optik" kriege ich Augenkrebs. Außerdem soll Microsoft, wenn Sie wollen dass die Entwickler auch eeeendlich WPF nutzen, finde ich das als einen richtigen Schritt diese Technologie selber in die Produkte einzubinden.

PS: Ein toller integrierter WPF-Editor wäre toll, womit man alle Vorteile von WPF auch ausnutzen kann!
 
@Samin:
woher willst du das wissen?
 
@.NET Developer: Weil ich kein VB.NET entwickel. Das einzig bunte was ein ernsthafter Entwickler sehen will ist Syntaxhighlight. @patrick_schnell: ein vernünftiger WPF-Editor (der in VS08 ist ja schon *etwas* besser geworden) wird wirklich endlich Zeit..aber ich will keine Animationen und buntes geblinke in meinem IntelliSense. Darum geht es mir. Für die GUI-Entwicklung ist WPF ein muss..weil der Kunde *will* Klickibunti, also muss da auch der Entwickler durch..aber bitte so wenig wie möglich *g*
 
@Samin:
deine aussage ist definitiv falsch!
 
@.NET Developer: Nein, ich entwickle tatsächlich kein VB.NET. Nicht eine einzige Zeile.
 
@Samin:
ich auch nicht. .NET ist logischerweise C$, auch wenn man VB oder C++ syntax verwenden kann, aber wer das tut ist selber schuld.

WPF bedeutet noch lange nicht, dass animation verwendet werden müssen. WPF ist eine neue graphische oberfläche, die nichts mehr mit dem alten message basierendem windows system zu tun hat. daher ist sie auch performanter und leistungsfähiger als das alte windows system.
damit meine ich nicht gdi, oder gdi+, was das graphische subsystem darstellt. gdi+ wird schliesslich auch von wpf verwendet.

mitlerweile habe ich viele graphische oberflächen, die ich entwickelt habe, auf wpf portiert und kann daher definitiv sagen, dass wpf perfomanter ist. die tatsache, dass wpf als xaml definiert wird und daher quasi ersteinmal analysiert werden muss, spielt dabei keine rolle, da einmal das xaml komprimiert wird und ausserdem praktische tests gezeigt haben, dass es keinen performanceverlust gibt.
 
@.NET Developer: 1. muss dich enttäuschen .NET ist nicht an C$ gebunden. Du kannst .NET in vollem Umfang mit VB.NET, F$ usw nutzen. (.NET sind nur ein paar Klassenbibliotheken und eine Laufzeitumgebung, alles was am Ende in im MSIL übersetzt wird ist .NET)
2. Wenn du WPF so nutzt dass es "nur" grundlegende Funktionen nutzt, dann kannst du es auch lassen. Wenn du aber Neuerungen nutzt wird es langsamer - auf normalen Systemen und keinen Vistarechnern.
 
@Samin:
als innhaber von 3 mcpd und 11 mcts zertifikaten brauchst du mir das nicht zu sagen. was ich meinte war, dass kein ernsthafter developer eine andere sprache als c-sharp für .net verwenden würde. dass es noch andere sprachen für .net gibt, auch von drittherstellern, wie delphi, das ist mir schon klar.

sofern man keine anwendungen schreibt, die für os<winxp laufen müssen, kann ich nur wpf empfehlen, aufgrund der performance. ausserdem ist es wesentlich einfacher oberflächen damit zu entwickeln, wenn man sich erstmal eingearbeitet hat.
 
@.NET Developer: Und warum ist man Deiner Meinung nach kein "echter Entwickler", wenn man eine andere Sprache als c sharp einsetzt?
 
@.NET Developer: Das mit den "ernsthaften Entwicklern" möchte ich so nicht stehen lassen. Unabhängig von der Sprache wird am Ende doch sowieso alles derselbe IL-Code! Hmmm, also wir entwickeln in unserem Team für einen internationalen Großkonzern (>50000 Mitarbeiter) von Anfang an (.NET 1.0) bis heute (.NET 3.5, VS2008) alles mit VB.NET, von WinForms über Web-Anwendungen bis hin zu unseren WebServices - und noch nie, an keiner Stelle, hat sich uns oder unseren Kunden der Eindruck aufgedrängt, dass das, was wir da machen, irgendwie nicht "ernsthaft" oder professionell sei...
Egal, wie viele Zertifikate Du erworben haben magst, ich glaube in der Frage der zu verwendenden .NET-Sprache solltest Du Dein Know-How mal etwas auffrischen bzw. die Scheuklappen etwas öffnen. Die Sprach-Grabenkriege sind seit .NET noch sinnloser geworden, als sie es ohnehin schon immer waren... :-)
 
C++/CLI und C Sharp haben innerhalb der .Net Infrastruktur dennoch eine gewisse Sonderrolle inne. Was ich allerdings ziemlich lächerlich finde ist die Tatsache nicht mit VB.net zu entwickeln als Argument für seine Kompetenz zu verwenden. Ich finde zwar selbst die VB Syntax ziemlich nervig, aber Sprache an sich erfüllt ja deshalb auch ihren Zweck sehr gut.
 
@guitarman: Sehe ich genauso, was .NET Developer da schreibt, lässt mich doch ernsthaft an seiner Kompetenz zweifeln, aber ist ja nicht so schlimm, solche muss es ja auch geben :). Was WPF Angeht, ist das für Entwickler die sich auf den Homeuser konzentrieren bzw. für diesen entwickeln meiner Meinung nach erst wichtig, wenn sich das FW3 auch durchgesetzt hat, was momentan noch nicht der Fall ist. Standard GUIs braucht man eh nicht mit WPF Entwickeln, dass ist absolut unnötig und bringt auch keinerlei Vorteil. Erst bei richtig aufwendigen Grafischen Spielereien wird WPF interessant.
 
@guitarman: Seh ich genauso. Kam ja auch seitdem nix mehr, was auch darauf schließen lässt, dass er keine Argumente für seine Behauptung hat. Vermutlich stützt er sich auf diesen uralten Pseudo-Benchmark von Shawn Weisfeld (http://tinyurl.com/shawnweisfeld), welcher allerdings recht schnell auseinander genommen wurde (http://tinyurl.com/eamonnerbonne). Ansonsten gibts keinerlei belegbare Beweise, dass c.sharp in irgendeiner Weise performanter wäre. Alles heiße Luft. Und zur "grauenvollen Syntax": Ich z.B. hab schon vor 20 Jahren mit Basic rumgespielt, insofern ist für mich alles c-ähnliche ein Graus. Ich kanns lesen und wenn nötig auch schreiben, aber mir persönlich liegt die VB-Syntax halt mehr. Ist alles eine Frage der Gewohnheit. :)
 
Meiner Meinung nach ist JEDE VS Version resourcenfressender, aufgeblähter und unübersichtlicher geworden. Wenn ich mir dann noch das .NET Framework anschaue... Wie gewollt und nicht gekonnt. Wenn ich mir dann noch VS C++ 2008 anschaue. Da hat M$ vergeblich versucht, C++ neu zu erfinden. Das schlimmste sind die Windows API Aufrufe. Die sind eigentlich für VB optimiert und man kann diese nicht sehr effekitv einsetzen, da VB grundsätzlich andere Datentypen verwendet und bei jedem API-Aufruf die Parameter zuerst konvertiert werden müssen und das hat natürlich zur folge, das die API-Aufrufe sehr langsam sind. VB und C$ sind meiner Meinung nach nicht für effektive Programmierung geeignet.
 
@kfedder:
dann solltest du dich unbedingt mal in die materie einarbeiten, dann wirst du feststellen um wie viel effektiver c-sharp ist, sowohl von der programmierung als auch von der ausführung.

richtig verwendet, gibt es auch bei komplexen arrayoperationen keinen performanceverlust, auch wenn .NET jit code ist. den proof of concept habe ich bereits 2005 gemacht, indem ich hochoptimierten c++ source der mit listensortierung und filtern arbeitet auf c$ portiert habe.
ergebnis: sowohl die performance als auch der speicherverbrauch war überraschenderweise geringer als mit native c++.

und mit linq ist die performance und effektivität nocheinmal um einen weiteren level gestiegen.
 
@kfedder: C$ ist schon länger leistungsfähiger und schneller als C und C++ - aber das ging wohl an einigen Vorbei. Kannst ja gerne mal ein wenig bei Google nach "C$ vs C++ Benchmarks" schauen :>
 
@kfedder: "Das schlimmste sind die Windows API Aufrufe. Die sind eigentlich für VB optimiert und man kann diese nicht sehr effekitv einsetzen, da VB grundsätzlich andere Datentypen verwendet und bei jedem API-Aufruf die Parameter zuerst konvertiert werden müssen" Das musst du mir mal erklären. Beziehst du dich nur auf .net, also behauptest das P/Invoke von .net sei auf VB.net optimiert, oder wie ist der Kommentar zu verstehen?
 
@TiKu: Schau dir doch mal den Resourcenfressenden Code an, der mit VS erstellt wird. Egal mit welcher Sprache. Die meisten VS Programmierer haben doch überhaupt keine Ahnung mehr von resourcenschonender Programmierung. Als ich ende der 80er mit C/C++ angefangen habe, da musste man teilweise mit jedem Bit rechnen. Heutzutage müllen die Programmierer den Speicher voll und verlassen sich auf die schlechte "Garbage Collection" von Windows Und wenn ich dann teilweise die Sourcecodes von Heute sehe. Die bestehen doch fast nur aus Workarounds, durch die die Entwickler selbst nicht mehr durchblicken. und dann diese ganzen Klicktools in VS machen den rest. Visual Studio ist von einer Effektiven IDE weit entfernt. Der größte Vorteil von C/C++ sind doch die Zeiger. Mit Zeigern kann man doch sehr schnelle und effektive Programme entwickeln. Die wenigsten haben doch überhaupt das Funktionsprinzip von Zeigern verstanden. Moderne 3D spiele wären ohne Zeiger völlig langsam. da man ohne Zeiger z.B. keine Polygone in angemessener Geschwindigkeit verschieben könnte. Also, Visual Studio ist nicht die Effektivste IDE. Eine Klickibunti GUI macht noch lange keine effektive IDE.
 
@kfedder: Du schreibst zum Teil ziemlichen Müll. 1) Das Windows-API hat erstmal rein gar nichts mit Visual Basic zu tun und ist auch nicht auf Visual Basic ausgelegt. Im Gegenteil, mit VB6 muss man zum Teil ganz schön tricksen (die Datentypen machen da oft Probleme) um API-Funktionen nutzen zu können. Denn das Windows-API ist klar auf C ausgelegt. Bei .net laufen API-Aufrufe über P/Invoke. Die Syntax erinnert in der Tat an die von VB6. Das liegt aber schlicht und ergreifend daran, dass man beim Entwurf von VB6 vor dem gleichen Problem stand wie später bei .net (API-Aufrufe sollten durch die jeweilige Laufzeitumgebung überflüssig sein, für Notfälle sind sie aber prinzipiell möglich).__-
2) Windows hat keine Garbage Collection.__-
3) Du kannst auch mit Visual Studio 2008 bzw. Visual C++ 2008 C/C++-Programme wie in den 80ern schreiben, also mit Zeigern usw. Das mache ich täglich. Du bist nicht gezwungen .net zu nutzen. C++/CLI, welches du vermutlich mit der "Neuerfindung" meinst, musst du nicht nutzen.__-
4) Das Hantieren mit Speicheradressen ist Fluch und Segen zugleich. Ja, es ermöglicht eine sehr hohe Geschwindigkeit. Aber es ist auch sehr fehleranfällig.__-
5) "Visual Studio ist von einer Effektiven IDE weit entfernt. Der größte Vorteil von C/C++ sind doch die Zeiger" Du vermischst (nicht nur hier) IDE und Programmiersprache.__-
Spätestens seit der Version 2005 mag ich Visual Studio und möchte es nicht mehr hergeben. Es ist zwar etwas schwerfällig, ich bekomme dafür aber u. a. einen sehr komfortablen Editor und einen sehr komfortablen Debugger. Deshalb kann ich mit der Schwerfälligkeit leben. Den WPF-Designer finde ich in den aktuellen Versionen aber auch nicht so toll. Ich habe mir deshalb angewöhnt, direkt den XML-Code einzugeben wenn ich etwas mit WPF mache.
 
@TiKu: "Du schreibst zum Teil ziemlichen Müll" ... Zum Teil? Der schmeißt doch absolut alles durcheinander. VB, C++, CSharp, .NET, API und das .NET Framework. Also ich bin schon ausgestießen als er bahauptet hat dass die API-Aufrufe auf VB ausgelegt sind *lol* @kfedder: Zeiger sind der absolute Obermist und IMHO für >90% aller Buffer Overflows verantwortlich. Das fast unkotrollierte, grenzenlose Schreiben in irgendwelche Speicherbereiche über Pointer sollte für die Anwendungsprogrammierung überhaupt nicht genutzt werden. Das ist mehr was für hardwarenahe Programmierung, z.B. bei Treibern. Da kann man froh sein, dass es .NET gibt. Dort gibts übrigens auch Zeiger. Nur sinds da keine "nativen" Zeiger, sondern Referenzen unter dem Dach der CLR. Sicherer, fehlerunanfälliger und fast genauso schnell.
 
Also wenn die gesamte Oberfläche mithilfe der WPF gestaltet wird, wird es schon zu einem gewissen Performance-Verlust und einer RAM-Zunahme kommen. (wie z.B. auch bei Expression Blend)
Da die Leistung der Hardware aber sowieso steigt, wird dieser Nachteil wahrscheinlich langsam an Priorität verlieren.
 
@f!R: Verwendet WPF nicht auch Funktionen der Grafikkarte über DirectX, wie z.B. Dreamscene und Aero Glass? Dann dürfte es nicht wesentlich langsamer werden wenn man ne DX9-Karte hat.
 
Mir gefällts ... VS 2008 nutze ich lieber als das alte angestaubte 2003 oder noch frühere Versionen. Freue mich auf die neue Version!
 
@voodoopuppe: Dito! VS2008 ist schon meine "liebste Anwendung" :-)
 
@voodoopuppe: Also ich arbeit ja immernoch mit dem guten alten Visual Basic 6.0 :-) und für W3.1-Anwendungen mit VB4 :-)
 
Das geplante Instant Messaging begrüße ich, denn es ist doch viel Arbeit in einem internen Entwicklernetzwerk ohne Abindung an das Internet einen Instantmessaging-Server zu betreiben.

Die WPF Oberfläche würde ich nicht pauschal verteufeln, WPF ist ein sehr durchdachtes Werkzeug und muss nicht unbedingt zu einem exorbitant höherem Verbrauch führen. Bei Visual Studio 10 gibt man sich hoffentlich mehr Mühe, als bei Expression Blend 2.5, dieses vernünftig umsetzen. Ich denke aber, dass bei Expression der Zeitdruck Silverlight schnell auf den Markt zu bringen auch eine große Rolle spielt und Optimierungen nachrangig sind.
 
Wird es dann wenigstens möglich sein, den Hintergrund eines Labels *durchsichtig* zu machen? Und nicht immer die Containerfarbe zu haben?
Habe bis heute weder bei VS2005, noch 2007 rausgefunden, wie man ein Label auf ein Bild platziert ohne den grauen Hintergrund.
Irgendjemand ne Idee wie das geht? Oder seh ich nur den Baum vor lauter Wäldern nicht? =D
 
@Ensign Joe:
Label1.Parent = PictureBox1
Label1.BackColor = Color.Transparent
 
Wie isses denn mit der integrierten Lokalisierungsfunktion? Die war bei VS2005 und ist bei VS2008 mehr als bescheiden und produziert viele Fehler. z.B. hats bei VS2005 oft die Events auf Controls weggehauen wenn man lokalisiert hat. Sehr ärgerlich wenn man dann beim präsentieren merkt dass die Buttons nicht mehr reagieren *grrrr*
Kommentar abgeben Netiquette beachten!

Video-Empfehlungen

WinFuture Mobil

WinFuture.mbo QR-Code Auch Unterwegs bestens informiert!
Nachrichten und Kommentare auf
dem Smartphone lesen.

Folgt uns auf Twitter

WinFuture bei Twitter

Interessante Artikel & Testberichte

WinFuture wird gehostet von Artfiles