Visual Studio 2010: Release Candidate via MSDN

Entwicklung Microsoft hat den ersten Release Candidate seiner Entwicklungsumgebung Visual Studio 2010 fertiggestellt. Ab sofort steht die neue Testversion für MSDN-Abonnenten zum Download bereit. mehr...

Diese Nachricht vollständig anzeigen.

Jetzt einen Kommentar schreiben
 
Die Express Editions wird es weiterhin geben, also mehr als 3 Versionen.
 
@cathal: Mit dem Unterschied das Visual Studio Express eine eigene Produktreihe ist.
 
@CHAOS.A.D: Eigendeich nicht, die Express Editionen sind lediglich die jeweiligen Einzelanwendungen, dass was ganz Früher (bis v2003) Standard Edition hieß. Der Kern ist hier der gleiche...
 
@e-hahn: Es sind eingeschränkte Varianten davon. Z.b. gibt es kein Remote-Debugging oder das Verwaltungssystem für die Quellcodes fehlt ebenfalls, kein MFC, kein Resourceneditor, man kann keine Anwendungen für den mobilen Bereich erstellen und noch einiges mehr. Allerdings darf man die Express Editions auch kommerziell einsetzen. Wenn du mehr haben willst, musst du, wie bei MS üblich bezahlen, oder wechselst einfach auf eine andere IDE.
 
@tekstep: Ob die EE noch mehr Beschränkungen aufweisen spielt keine rolle, im Kern ist es dennoch das gleiche. Solch Software ist intern modular aufgebaut, je nach dem welche Edition angeboten wird, werden Funktionen eingeschaltet bzw. zugänglich gemacht oder nicht.
 
Als ich programmierer werden wollte, hatte ich damit einen verbundenen Traum ... ich wollte das jeder der meine Software nutzen wollte, es auch konnte. Das ist nunmehr 10 Jahre her ... man das waren noch Zeiten ^^
 
@kinterra: liegt aber am programmierer, ob die software benutzbar ist
 
@kinterra: Was willst du uns damit sagen? Du fandest die DLL-Hölle doch nicht besser als ein einheitliches Framework, oder?
 
@satyris: die "DLL-Hölle" war aber Modularer. Das einheitliche Framework zerrt ganz schön an der Leistung.
 
@Aurelia: An welcher Leistung? Der heutigen 3 GHz Rechner (von Multi-Core ganz zu schweigen)? Eine in Maschinencode kompilierte CSharp-Methode läuft bewiesenermaßen nicht langsamer als sein C++ Pendant. Und die "Schrecksekunde" für MSIL -> Maschinencode fällt nur beim ersten Aufruf ins Gewicht. Edith sagt: WF lässt keine Raute zu.
 
@satyris: Was?! ... Nee, soweit kam es gar nicht. Ich habe mich leider für die holde Isolde entschieden ... Kathleen oder Katrin glaub ich hieß sie :p ... gelernt habe ich wiederum etwas anderes. Aber egal ob DLL-Hölle oder .Net, beides ist für mich Bullshitt :)
 
@satyris: Also ich finde es erschreckend wie lange Programme wie damals nlite oder vlite, heute Paint.NET zum starten brauchen. Manch komplexere Programme tun dies schneller. 3ghz hin oder her. Aber davon auszugehen das jeder einen 3ghz Rechner hat, nur weil es die schon seit Jahren gibt, ist auch ne große Nummer.
 
@Aurelia: Mein XP hatte bis zuletzt, kein .Net. Aus dem selben Grund, wie du es nennst nur das mit .NET der XP nochmals langsamer wird. Bei Win7 ist der Schmodder leider integriert.
 
@kinterra: Wegen .NET wird XP nicht langsamer. Du bist sicher auch einer von denen die denken, dass TuneUp usw ihr System wirklich merkbar schneller macht... Aber hey, ich lass dir deinen Traum :)
 
@cH40z-Lord: Nee ... sowas nutze ich auch nicht. Wer echtes tunig will, sollte ein anderes OS einsetzen. Das ist aber kein Traum :)
 
@Aurelia: Paint.NET braucht nicht lange zum starten... außer das framework ist nicht geladen. hackt mal lieber auf java rum ^^, .NET ist schon ganz okay.
 
@kinterra: Kannste .NET bei Windows 7 nicht runterschmeißen? Müßte unter "Windows Funktionen ein/ausschalten" gehen. Bringen tuts aber nix. Außer dass man ein paar 100 MB mehr freien Speicher hat. @Aurelia: Eigentlich kann das nicht sein. .NET Programme brauchen nur beim ersten Start nach der Installation recht lange. Startet man sie dann ein 2.,3.,4. Mal sollte der "Lag" weg sein.
 
@KainPlan: Java ist wenigstens Programmunabhängig, da ist eine Verzögerung zu verzeihen.
 
@DennisMoore: Paint .NET startet beim 3. mal wie beim ersten mal.
 
@Aurelia: "Java ist wenigstens Programmunabhängig" klaro, wem willste das denn erzählen, auch für jar files brauch ich ein programm wie "JAVA" um eben in java geschriebenes zu starten, das is im übrigen bei fast allen compiler & recompiler der fall, also auch bei NET, C++ etc.
 
@Aurelia: Was meinst du mit "Programmunabhängig"? Verstehe deine Aussage irgendwie gar nicht. Und langsamer ist Java was GUI angeht allemal!
 
@hellboy666: Öhm da hat ja mal jemand keinen Plan xDDD
1. .NET benutzt ein JIT-Compiler der den code wärend der laufzeit in maschinencode umsetzt. (dadurch weesentlich schneler als JAVA)
2. JAVA nutzt einen Interpreter zur code ausführung.
3. C/C++ wird kompiliert zu maschinencode. da hängt nükkes dazwischen.
 
@KainPlan: jein, NET nutzt unter anderen "auch" JIT wenns darauf hin gesetzt wurde, am sonsten hat NET auch "nur" nen Interpreter, nehmlich (jetzt lachen) NET.

Das alles hat mit meiner aussage aber wenig zu tun, kernpunkt war bei mir die von Aurelia aufgestellte these, das java anwendungen kein Programm zum ausführen brauchen & das is nunmal nicht der fall & solch fälle sind auch mehr die ausnahme, das die basic programme meist eh bestandteil des OS sind.
 
@hellboy666: Programm kann man das häufchen elend ja auch nicht nennen was JAVA zur code ausführung benutzt.. in sofern hat Aurelia schon recht... ^^ Ich bin heute zu Entschuldigen ich muss gleich noch bis 21.30 Uhr in die uni.. Aber stimmt schon Java ist "Programm abhängig". JAVA ist, nach eigenen aussagen, Plattform unabhängig. Das stimmt dann aber auch nur in sofern das für die besagte Plattform schon ein Interpreter existiert.
 
@hellboy666: Bei .NET wird nix interpretiert. Es kommt IMMER zur JIT-Übersetzung. Aus MSIL wird Maschinencode generiert während der Ausführung. Das ist was anderes als Interpretieren.
 
@KainPlan: .NET ist nur ein Framework! Programme die .NET nutzen kannst du in C$, C++ oder auch VB.NET schreiben! Eben aus dem Grund, da das ganze in Byte Code kompiliert wird(IL-Code) und während der Laufzeit dieser in Maschinencode übersetzt wird(JIT-Compiler)!
 
@Fonce: Nein, das .NET-Framework ist nur ein Frameworl, .NET ist eine Technologie. Zu der gehört auch der JIT-Compiler usw.
 
@DennisMoore: Kann sein, das man es runter machen kann. Aber wer weiß dann, was danach nicht gehen tut. Ich meine, die haben sich was dabei gedacht, wenn die es integriert haben ( mal von der zwangsverbreitung abgesehen ). Ich habe schon den IE deaktiviert und einiges geht/ging nicht mehr so wie gewohnt oder gar nicht. Bevor ich mein Win OS kaput repariere, soll es drauf bleiben. Wer weiß vielleicht brauch ich es mal wirklich.
 
@kinterra: Naja, du kannst dann halt keine Programme mehr nutzen die irgendeine Version von .NET benötigen, selbst wenn sie ne .NET Runtime installieren wollen. Standalone-Installer funzen da nicht mehr und bringen nur ne Fehlermeldung. @Aurelia: Gerade ausprobiert. Nach der Installation rödelt er etwas rum und startet das Programm etwas verzögert. Ab dem 2. Mal geht es wesentlich flotter, wenn auch nicht ganz so zügig wie bei nativ programmierten Anwendungen.
 
Bis wann läuft denn die Timebomb eigentlich?
 
@karstenschilder: Bei der Beta2 bei mir noch 140 Tage, ist aber die Frage, ob das von nem Datum abhängig ist oder ob die Version nach der Installation einen bestimmten Zeitraum von Tagen läuft. RC müsste mal jemand nachschauen, steht in "Help - About..."
 
Weiß einer, ob sich der Team Foundation Server updaten lässt, bzw. sich die Datenbanken der Collections sich problemlos anhängen lässen? Hab dieses Wochenende erst die Beta aufgesetzt und schon meine Projekte da eingerichtet.
 
Downloads des RC sind jetzt für alle auf der Microsoft Downloadseite verfügbar
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