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)

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

Eigentlich sollte man ja meinen, dass dies Beispiel zumindest einigermaßen funktioniert… leider weit gefehlt…

Das Problem ist: Sobald wir ein eigenes DataTemplate für spezielle Daten gemacht haben, hat ein Klick auf ein Element nur dann reagiert, wenn entweder genau auf den Rahmen des Items geklickt wurde oder genau auf den Text:

Es ist also relativ schwer z.B. das “!” genau zu treffen…wir haben ewig gesucht, bis wir endlich den Grund gefunden haben… (dank Franks Unterstützung haben wir es mittels Snoop und der Event-Ansicht gefunden): Der Border in dem ControlTemplate hat keine Hintergundfarbe. Somit ist der Border “durchsichtig” (bzw. “x:Null”), was dazu führt, dass ein Klick auf den Border nicht vom Border verarbeitet wird, sondern vom darunterliegenden Scroll-Container… und der macht natürlich hier nichts damit…
Hier ist auch ein Beispielprojekt (VS2008), damit man es mal selber probieren kann.

Für uns jetzt mal die Lösung: Wir setzen einfach die Hintergrundfarbe des Borders des ControlTemplates auf “Transparent”, dann wirken sich jetzt überall die Klicks auf die ListBox aus… danke an Hendrik für diesen Hinweis!

Und wer sich gleich noch über die Neuerungen in der MFC informieren will (ja die gibt es!), kann sich hier ein Video anschauen:
Pat Brenner: Visual Studio 2010 - MFC and Windows 7

Aber nun ist es nunmal anders und wir sind entweder gezwungen das Security-Update von VS2008 nicht einzuspielen (was ich aktuell als einzige Lösung hier im Automatisierungs-Bereich habe, wenn man auch alte Systeme updaten muss) oder auf neuen Systemen das passende vcredist zu installieren.

Nur jetzt ist wieder die Frage: Welches ist denn nun die “richtige” vcredist…
Hier die Auflistung der aktuell verfpgbaren Versionen:

• VC2008 Runtime with SP1 and ATL hotfix
• VC2008 Runtime with SP1
• VC2008 Runtime with Feature Pack
• VC2008 Runtime with ATL hotfix
• VC2008 Runtime (RTM)

Wer ganz sicher gehen will, der sollte ab sofort nur noch das oberste installieren!

var dv = CollectionViewSource.GetDefaultView(viewModel.MeineCollection);
dv.MoveCurrentTo(viewModel.MeineCollection[1]);

oder um das CurrentItem auszulesen:

var dv = CollectionViewSource.GetDefaultView(this.List);
MessageBox.Show(dv.CurrentItem.ToString());

Hier gibt es auch ein kleines Beispielprojekt: WPF_CurrentItem.zip

Alles im allem muss ich sagen, dass ich sehr zufrieden bin. Leider musste ich dann natürlich wieder alles installieren, was man so braucht… und die Daten wieder rüberkopieren.

Also, ich kann es nur empfehlen auf Windows 7 umzusteigen. Es macht einen schönen und performanten Eindruck.

Jetzt dürft ihr auch gerne zu meiner Windows 7 HouseParty kommen