Download x86 Edition (235 MB)
Download x64 Edition (247 MB)

Der einzige Nachteil des Nachfolgers ist, dass es nur noch auf einem x64 System installiert werden kann.
Wenn man es auch auf einem Entwicklungsrechner installieren will, so kann man es auf Vista (SP1-x64) oder Win7 (x64) installieren. Produktiv wird dies aber nicht unterstützt.
Hier wird dann schon mehr verlangt:

• x64 - 4 cores
• 8 GB RAM
• 80 GB HD

Ab VS2010 sieht man an dieser Stelle nur noch:

Der Grund hinter der Änderung liegt daran, dass ab VS2010 die IDE das “Multi-Targeting” unterstützt. D.h. man kann mit der gleichen IDE z.B. für VS2010 und auch für VS2008 compilieren! Deshalb kann man natürlich die C++ Pfade nicht mehr der IDE zuordnen, sondern diese müssen dem jeweiligen Projekt zugeordnet sein.

Man kann aber auch weiterhin Pfad Benutzerspezifisch hinzufügen. Dies wird dann über Property-Sheets realisiert. Dies zu finden, ist aber etwas komplizierter, deshlab hier eine kurze Erklärung:

1. Öffne irgendein VC++ Projekt
2. Zeige den Property-Manager an (View|Other Windows|Property Manager)
3. Expandiere die Knoten dort (i.d.R. Debug/Release)
4. Wähle dort alle Einträge mit “Microsoft.cpp..user” aus (Multi-Select)
5. Dann ein rechter Mausklick auf eine der Selektionen und “Properties” auswählen
6. In dem Dialog kannst Du nun “Common Properties|VC++ Directories” auswählen und dort die entsprechenden Einträge hinzufügen.
   

7. Ich persönlich würde links die Dropdown-Liste auswählen und dort dann Edit drücken und die Pfade in dem dann Folgenden Dialog eingeben.

Noch mehr Infos zum Upgrade auf VS2010 gibt es hier:
Visual Studio 2010 C++ Project Upgrade Guide

Anmerkung: Es sei noch erwähnt, dass man zusätzliche Include-Pfad für ein Projekt immer noch in den Projekteinstellungen vornehmen kann! Dazu sind diese Anpassungen NICHT nötig!

Anmerkung2: Um bei der Express Version den Property-Manager zu sehen, muss man erst die Expretenansicht aktivieren:

Tools | Setting | Expert settings

Ich kann es wirklich nur jemdem empfehlen daran teilzunehmen, der auch zukünftig noch VC++ einsetzen will!

Es ist also zukünftig möglich via RDP die schöne, neue 3D-Welt zu erfahren.
Dies bedeutet natürlich auch, dass ein Arbeiten mit VS2010, welches ja WPF verwendet, vermutlich flüssig über RDP möglich ist!

Also, ich bin mal gespannt und freue mich schon auf dieses Feature, da ich oft RDP verwende!

RemoteFX!

Edit 2010-03-27:
Hier gibt es auch noch eine ausführlichere Erklärng wie RemoteFX funktioniert:
http://blogs.msdn.com/rds/archive/2010/03/26/microsoft-remotefx-the-problem-we-are-solving.aspx

Und ein Anfänger will natürlich gleich sichtbare Erfolge sehen und beginnt logischerweise gleich mit einer Fenster-Anwendung.

Leider enthält die VC2008/2010EE nur WinForms als graphische Oberfläche. Deshalb entwicklen die meisten dann nicht mit C/C++, sondern mit C++/CLI, was eine komplett andere Sprache ist und für die meisten nur zu Verwirrung führt.

Ich Rate jedem Anfänger davon ab VC 2008/2010 Express Edition für graphische Oberflächen zu verwenden, aus folgenden Gründen:

• Der WinForms-Designer ist miserabel, da er die Implementierung von Methoden in der h-Datei vornimmt, was spätestens zu Problemen führt, wenn man mehr als ein Form hat und auf Methoden/Properties des anderen Forms zugreifen will (da man dann zyklische Abhängigkeiten in den h-Dateien hat, die man nur lösen kann, wenn man die Implementierung in die cpp-Datei verlegt)
• Wenn man die Anwendung verteilen will, so muss man neben dem .NET-Framework auch die C-Runtime installieren; das muss man bei einer reinen .NET-Anwendung (z.B. C#) nicht
• C++/CLI ist primär als InterOp Sprache zwischen .NET und native Code gedacht; das sieht man auch schon daran, dass seit VC2008 auch der Data-Wizward für C++/CLI entfernt wurde. Daraus ergibt sich gleich der nächste Punkt:
• Der Data-Wizard wurde in VC 2008 entfernt um auch deutlich zu machen, dass der Focus auf native-managed InterOp liegt
• Ca. 99% aller Beispiele im Internet sind mit C#; man findet fast keine Beispiele in C++/CLI
• C++/CLI ist eine eigene Sprache und hat mit (ISO) C/C++ nichts zu tun; und das ganze zu mischen ist meistens noch viel sinnfreier, es sei denn, man weiss was man tut (was zu 99% nicht der Fall ist; zumindest in den Fragen, die ich aus den Foren entnehme)
• C++/CLI wird oft als “Erweiterung” von C/C++ gesehen. Diese Sicht ist aber komplett falsch! Ganz einfacher Beweis: Versuch in einen STL-Vector ein CLR Objekt reinzustopfen (z.B. std::vector). Wenn es gehen würde, dann könnte man C++/CLI als Erweiterung sehen. Es geht aber nicht. Deshalb sind es zwei komplett getrennte Welten!
• In VS 2010 wird es für C++/CLI Projekte kein Intellisense geben; das deutet auch stark darauf hin, dass es nicht als primäre Sprache für .NET geeignet ist

Meine Empfehlung für Anfäger:
Wenn Ihr unbedingt graphische Oberflächen machen wollt, dann nehmt lieber C# (gibt es auch als Express Edition).

Meine Empfehlung für Microsoft:
Wenn Ihr auch mit VC++ Anfänger erreichen wollt, dann liefert bitte die MFC in der Express-Edition mit; oder bindet von mir aus wxWidgets ein

Die Frage ist einfach zu beantworten, wenn wir davon ausgehen, dass das Programm mit VS2008 erstellt wurde:

1. Zuerst wird das .NET Framework benötigt (da C++/CLI ja die CLR verwendet). Aktuell ist dies die Version 3.5SP1:
   .NET 3.5 SP1 (Full download)
   Damit es aber auch Problemlos läuft wird min. noch dieser Hotfix anschliessend benötigt:
   An update for the .NET Framework 3.5 Service Pack 1 is available

2. Und da Du C++/CLI (also C++) verwendet hast, benötigst Du noch die C-Runtime DLLs, da C++/CLI (CLR) nur mit der DLL-Version der C-Runtime (CRT) verwendet werden kann:
   VC2008 Runtime with SP1 and ATL hotfix

PS: Falls man kein CLI (CLR / .NET) verwendet hat, so ist es meistens einfacher, wenn man statisch gegen die CRT linkt!

1. Welche Version hat der Kunde?
2. Welche Source-Files brauche ich für diese Version?
3. Wo zum teu.. sind nochmals die passenden PDBs und EXEn für diese Version?

Mit diesem Fragen braucht man sich nicht beschäftigen, wenn man bei seinem Build Prozess noch zusätzlich zwei Dinge einbaut

1. Source-Indexing
2. Symbols-Store

Source-Indexing (mit dem TFS)

Source-Indexing sorgt dafür, dass in die Debug-Symole (PDB-Dateien) auch zusätzlich noch ein verweis auf die richtige TFS-Version eingefügt wird. Dadurch kann der Debugger (z.B. VS) man mit der PDB-Datei genau den passenden Source aus dem TFS holen, mit dem die DLL/EXE gebuildet wurde.
Um dies zu machen braucht man zwei Dinge: “Debugging Tools For Windows” und “ActivePerl“). Das Source-Indexing findet sich bei den Debugging Tools im Unterverzeichnis “srcsrv” (also z.B. C:\Program Files\Debugging Tools for Windows\srcsrv). Da die “Skripts” (leider) in Perl geschrieben sind, ist auch noch ActivePerl notwendig. Es reicht aber, wenn man die ZIP-Datei runterlädt und vor dem Aufruf einfach den Pfad auch noch auf das entpackte ActivePerl setzt.

Damit beim Source-Indexing auch der korrekte TFS-Server verwendet wird, muss man in der Datei “srcsrv.ini” die Zeile mit “MYSERVER” auf den richtigen TSF zeigen lassen.
MYSERVER=http://my-tfs-machine:8080

Jetzt muss man nach einen Build nur noch das Source-Indexing aufrufen und angeben, wo denn der Workstore und die PDBs liegen. Ich gebe der Einfachheithalber immer den Root aller Projekte an, welche ich gebuildet habe. Die Natchdatei sieht dann z.B. so aus (es kann auch direkt als eigenes Task in msbuild laufen):

rem Merke mit mal den aktuellen Pfad, was die Root meiner Projekte und Ausgabe ist
set srvOrgDir=%CD%

rem Setze wieder den ursprünglichen Pfad
cd /D %srvOrgDir%


Alternativ kann man natürlich auch das srcsrv-Verzeichnis im TFS ablegen (so hab ich es gemacht), dann muss man nicht sicherstellen, dass man auf dem Build-Rechner auch die Debugging-Tools installiert hat.

Jetzt sollten nach einem Build alle PDB-Dateien mit der korrekten TFS-Version indiziert worden sein (dies erkennt man daran, dass ziemlich weit hinten in der PDB-Datei Einträge mit “MYSERVER” kommen…; kann man z.B. in Notepad anschauen).

Symbol-Store

Oben haben wir jetzt die PDB-Dateien mit dem passenden Verweis auf den TFS ausgestattet. Jetzt müssen wir nur noch sicherstellen, dass wir zu einem beliebigen späteren Zeitpunkt nicht mehr nach dieser PDB-Datei (und den dazugehörigen EXEn) suchen müssen. Dies geschieht am einfachsten mit dem “symstore” aus den Debugging Tools for Windows. Dies speichert einfach alle PDBs/EXEn in ein Verzeichnis (am besten ein Netzwerkverzeichnis, wenn es später mehrere Verwenden wollen).
Das ablegen erfolgt dann ganz Simple durch:

.\Tools\SymStore\Symstore.exe add /r /f .\*.* /s G:\MyProject\SymbolStore\Files /t "Project Name"


Das war alles

Einstellungen in VS

Ok, fast… denn man will das ganze ja auch noch verwenden… dazu muss man in VS noch ein paar Einstellungen machen, da per default der “Source-Server” deaktiviert ist. Dies muss aktiviert werden:

Jetzt muss man noch den Pfad zu den zuvor abgelegten Dateien eintragen:

Bekommt man jetzt ein Dump oder will in dieser EXE/DLL debuggen, so werden die Sourcen direkt vom TFS geholt (und in einem temporären Verzeichnis gespeichert) und man kann dies dann direkt debuggen.

Ich hoffe, dass hilft dem ein oder anderen.

PS: Beide Verfahren werden übrigens auch intern von Microsoft schon sehr lange eingesetzt (deswegen auch das Source-Indexing in Perl; PowerShell gab es damals noch nicht). Die gesamten Windows Sourcen sind so indiziert und (der wer darf ) können dann via CCP die passenden indizierten PDB-Dateien abgefragt werden, welche dann z.B: in VS/WinDbg die passenden Source runterlädt.

PPS: Wer das ganze noch für SubVersion haben will, kann es bei Stefan nachlesen:
Source Server und Symbol Server Setup mit Subversion