Jochen Kalmbach’s Blog

C++ ist noch lange nicht tod! Microsoft hat in den letzten Jahren wieder mehr Resourcen in diesen Bereich investiert. Um wieder mehr auf diesen Bereich aufmerksam zu machen bzw. sich mal weider zu Informieren, was es alles gibt, solltest Du unbedingt auf einen der C++ Days gehen. Das beste dabei ist, das Ganze ist kostenlos! Also, gleich Anmelden:

• 2.2.2012 14:00- 18:00 Berlin (ausgebucht)
• 7.2.2012 14:00- 18:00 Bad Homburg (noch freie Plätze!)
• 13.2.2012 14:00- 18:00 Karlsruhe (noch freie Plätze!)
• 5.3.2012 14:00- 18:00 Köln (ausgebucht)

Mehr Infos unter:
http://blogs.msdn.com/b/cbinder/archive/2011/12/29/c-entwickler-uptodate-microsoft-c-day-2012.aspx

Seit kurzem sind die Hilfeseiten für VS2011 online.

Dabei sind auch die Neuigkeiten für VC 2011 aufgeführt.

Der Blick ist wirklich lohnentswert.

Das neue VS kann man sich auch schon zusammen mit Windows 8 runterladen:
http://msdn.microsoft.com/en-us/windows/apps/br229516

Wer es in einer VM installieren möchte muss das neue VMWare 8 nehmen, da es in VMWare 7.1.4 wohl nicht geht (siehe hier ).

Lange habe ich gerätselt, wie man verhindern kann, dass der XmlSerializer bei abgeleiteten Klassen immer nur als Element-Name die Basisklasse verwendet und dann im Attribute “xsi:type” den jeweiligen richtigen Typ reinschreibt/ausliest. Das sieht im XML immer sehr unschön aus:

<Liste>
  <BasisKlasse xsi:type="Ableitung01" />
  <BasisKlasse xsi:type="Ableitung02" />
</Liste>

Viel schöner wäre es ja, wenn direkt die abgeleitete Klasse in der Datei stehen würde:

<Liste>
  <Ableitung01 />
  <Ableitung02 />
</Liste>

Bisher hab ich sowas immer gemacht, indem ich das “XmlInclude” Attribut an die Root-Klasse rangehängt habe, um dem XmlSerializer mitzuteilen, welche Klassen er noch berücksichtigen soll. Heute hat mir nun ein Kollege ganz nebenbei eine XML-Datei gezeigt, die genau das hat, was ich schon lange suche… Der Trick ist einfach nur, das “XmlArrayItem” Attribut an dem jeweiligen Property der Liste dranzuhängen… damit werden die Listen-Einträge dann ohne “xsi:type” serialisiert und bekommen den lesbaren Namen

Hier ein kurzes Beispiel wie sowas aussieht:

using System.Collections.Generic;
using System.Xml.Serialization;

namespace ConsoleApplication_VS2010
{
  public abstract class BaseObject {}

  public class Special01 : BaseObject {}
  public class Special02 : BaseObject {}

  public class Root
  {
    readonly List _Objects = new List();

    [XmlArrayItem(typeof(Special01))]
    [XmlArrayItem(typeof(Special02))]
    public List Objects
    { get { return _Objects; } }
  }

  class Program
  {
    static void Main(string[] args)
    {
      var r = new Root();
      r.Objects.Add(new Special01());
      r.Objects.Add(new Special02());
      r.Objects.Add(new Special01());

      using (var sw = new System.IO.StringWriter())
      {
        var ser = new XmlSerializer(typeof (Root));
        ser.Serialize(sw, r);
        System.Console.WriteLine(sw.ToString());
      }

    }
  }
}

Dies ergibt dann:

<?xml version="1.0" encoding="utf-16"?>
<Root xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://ww
w.w3.org/2001/XMLSchema">
  <Objects>
    <Special01 />
    <Special02 />
    <Special01 />
  </Objects>
</Root>

Wer mal VS2010 SP1 Ultimate kostenlos testen will und dabei auh noch einige Hand-On-Labs machen will (incl. TFS Labs), der kann sich die VHD hier rinterladen:

http://blogs.msdn.com/b/briankel/archive/2010/06/25/now-available-visual-studio-2010-rtm-virtual-machine-with-sample-data-and-hands-on-labs.aspx

Ein kleiner Hinweis noch: Das Windows läuft am 1.November 2011 ab…

Wer neben der Installation von VS2010 (Express oder Professional) auch noch das separate Windows SDK v7.1 installiert hat, der sollte das VS2010 SP1 nicht installieren!
Wenn man das SP1 installiert so werden die Compiler und C++ Libraries der IA64/x64 Komponenten gelöscht!
Es scheint so, als ob die Premium und Ultimate-Versionen davon nicht betroffen sind.

Mehr dazu siehe:
Visual Studio 2010 Service Pack 1 and Windows SDK for Windows 7 and .NET Framework 4 Issue

Update (2011-03-31):
Es gibt wohl ein Hotfix dazu. Siehe:
Microsoft Visual C++ 2010 Service Pack 1 Compiler Update for the Windows SDK 7.1

Nachdem redgate angekündigt hat ab der nächsten Version 35$ für .NET Reflector zu verlangen, stellt sich ja die Frage, was man macht, wenn man doch oft das sehr nützliche Tool verwendet.

Seit kurzem gibt es eine Alternative vom SharpDevelop-Team: ILSpy
http://www.ILSpy.net/

Es ist zwar immer noch in Entwicklung, aber es sieht zumindest vielversprechend aus:

Ich hatte hier das Problem, dass wir in einen VIsual Studio Unit Test eine COM-DLL verwenden müssen. Diesen wollen wir aber nicht auf dem Build-Server registrieren. Um dies zu umgehen, hab ich mittels CreateActCtx / ActivateCtx / usw. eine Klasse gemacht, mit der man ein Manifest zur Laufzeit aktivieren kann. Jetzt war aber das Hauptproblem, dass die Unit-Tests ja von einer Applikation ausgeführt werden, auf dessen Verzeichnis wir keinen Zugriff haben. Im Internet hab ich aber immer nur Beispiele gefunden, wo die COM-DLL im gleichen Verzeichnis wie die EXE lag. Dies geht hier aber nicht, sondern die DLL muss mit einem “DeployItem” auch in das entsprechende Out-Verzeichnis kopiert werden und von dort muss diese COM-DLL dann geladen werden. D.h. das Manifest muss auf diese Datei zeigen.
Ich hab das nicht hinbekommen…. mein erster Versuch war das “lpAssemblyDirectory” Feld in der ACTCTX Struktur zu setzen. Damit hab ich es aber nicht hinbekommen; hab alles erdenkliche versucht… er hat immer gemeldet, dass er die Datei nicht finden kann…
Dann hab ich es in der Manifest-Datei selber probiert. Dort hab ich es nur hinbekommen, wenn der <file name="NameDer.dll"> auf den relativen Pfad geändert hab, also: <file name="test\NameDer.dll">.
Aber sobald ich einen vollständigen Pfad angegeben hab, ging es nicht mehr… ich bin fast verzweifelt…
Dann endlich kam ich drauf (keine Ahnung wie): Man muss den ganzen Pfad angeben, aber für jeden Slash jeweils *zwei* einfügen! Also:
<file name="C:\\Temp\\Test\\NameDer.dll">
Und siehe da: Es funktioniert, auch wenn die DLL nicht im entsprechenden EXE-Verzeichnis liegt.

Somit können wir jetzt Unit Tests erzeugen, welche eigentlich eine Registrierung von COM-DLLs auf dem Server verlangt hätten.

Mehr Infos dazu siehe:
https://cfx.svn.codeplex.com/svn/Visual%20Studio%202008/CSRegFreeCOMClient/Program.cs
http://www.mazecomputer.com/sxs/help/sxsapi2.htm

Leider gibt es in VS2010 bei C++/CLI Projekten keine Möglichkeite durch die Projekt-Eigenschaften einzustellen, welche .NET Version bei einem C++/CLI Projekt (/clr) verwendet werden soll.
Die einzige Möglichkeit ist es, dies direkt in der *.vcxproj-Datei vorzunehmen. Dazu sind Folgende Schritte notwendig:

1. Rechst-Klick auf das entsprechende Projekt im Solution Explorer und dann auf “Unload project” klicken
2. Dann nochmals ein Rechts-Klick auf das entladene Projekt im Solution Explorer und “Edit .vcxproj” auswählen

3. In the Projekt XML Datei nach dem Knoten suchen
4. In diesem Knoten nach dem Unterknoten such (wenn er nicht existiert muss man ihn hinzufüügen)
5. Der innere Text des Knotens definiert nun das TargetFramework. Es kann die Werte v2.0,v3.0, v3.5 oder v4.0 annehmen
6. Speichere die vcxproj Datei und schliesse sie
7. Dann nochmals ein Rechts-Klick auf das entladene Projekt im Solution Explorer und “Reload Project” auswählen

Beispiel:

  <PropertyGroup Label="Globals">
    <ProjectGuid>{089A9EBF-5149-462A-BC7E-2B1B59DE123C}</ProjectGuid>
    <Keyword>Win32Proj</Keyword>
    <RootNamespace>CPP_VS2010</RootNamespace>
    <TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
  </PropertyGroup>

Heute ab ich längere Zeit nach einem Bug gesucht. Der Folgende Code wollte einfach nicht die korrekte Differenz ausrechenen:

  int? geliefert = 3;
  int? aktuell = 2;
 
  int diff = geliefert??0 - aktuell??0;

Bis ich endlich draufkam, dass das Minus ja nie ausgewertet wird, da einfach der erste Wert zurückgeliefert wird…

Also gut, wieder was gelernt, wenn man den ??-operator verwendet. Hab das ganze in Klammer gepackt, dann ging es wunderbar…

int diff = (geliefert ?? 0) - (aktuell ?? 0);

Die Beta Version des VS2010 SP1 ist nun für alle Verfügbar. Wie immer gilt der Hinweis, dass man dies nicht auf einem Produktivsystem installieren sollte. Wobei diesmal aber auch eine “Go Live” Lizenz dabei ist; d.h. man darf es auch produktiv verteilen!

Das C++ Produkt-Team hat auch noch detailiertere Infos, was sich im C++ Bereich getan hat:
VS2010 SP1 Beta: What’s in It for C++ Developers
Die Hauptneuigkeit dürfte wohl sein, dass es wieder einen lokalen Help-Viewer gibt…

Und wer noch gleich Feedback geben will, kann das hier tun:
Visual Studio 2010 Service Pack 1 Beta Survey

Wer mit .NET “aufgewachsen” ist, der kennt das System.Threading.Thread.CurrentThread.CurrentCulture bzw. CurrentUICulture. Damit kann man z.B. in WinForms-Anwendungen die Formatierungen der Ausgaben beeinflussen. Diese Culture wird auch in den meisten Objekten verwendet wenn man “ToString()” aufruft. Bestes Beispiel dafür ist DateTime. Intern wird hier die aktuelle Culture (CurrentCulture) des aktuellen Threads verwendet.

Dieses ganze Konzept ist aber nicht so ganz WPF kompatibel. Dazu gibt es zwei Gründe: Erstens basiert bei WPF (fast) alles auf DependencyProperties, welche Vererbung und auch Änderungsbenachtrichtigungen schon automatisch unterstützen. Auch spielen die Converter eine große Rolle beim Anzeigen von Daten. Dabei wird immer eine Culture mitgegeben in den Konvertierungsmethoden mitgegeben. AUs diesem Grunde spielt die “Thread.CurrentThread.CurrentCulture” in WPF keine Rolle mehr!

Die Sprache wird in WPF also auch über ein DependencyProperty umgeschaltet: FrameworkElement.Language

Das kann man einfach testen indem man z.B. ein DateTime-Property an an TextBlock bindet. Dabei wird die Datum/Uhrzeit immer in en-us angezeigt! Egal welche Sprache nun das Betriebssystem oder den Benutzer hat. Ob dies ein Bug oder Feature ist, sei mal dahingestellt.

Um also beim Starten der Applikation die Sprache auf die aktuelle Sprache zu setzen, muss man für jedes TopLevel-Fenster das Language Property korrekt initialisieren, am besten im Konstruktor:

this.Language =
  System.Windows.Markup.XmlLanguage.GetLanguage(
    System.Threading.Thread.CurrentThread.CurrentUICulture.Name
  );

Will man eine Sprachumschaltung dynamisch machen, so könnte man auch ein Binding auf dieses Language-Property machen. Dazu muss man aber wissen, dass ja jedes Binding auch eine Culture hat. Da aber die Culture aus dem vererbeten “Language” DependencyProperty kommt beisst sich hier die Katze in den Schwanz… aus diesem Grund scheitert auch ein Binding der Form:

Language={Binding MyCurrentCulture.Name}

mit der Fehlermeldung (InnerException):
Binding for property 'Language' cannot use the target element's Language for conversion; if a culture is required, ConverterCulture must be explicitly specified on the Binding.
Wer diese Meldung genau liest erkennt, dass man für den Converter die Culture explizit vorgeben muss! Damit muss der Bindning Ausdruck z.B. wie folgt aussehen:

Language={Binding MyCurrentCulture.Name,
  ConverterCulture={x:Static glob:CultureInfo.InvariantCulture}}

Dabei ist der Namespace “glob”:

xmlns:glob="clr-namespace:System.Globalization;assembly=mscorlib"

Damit wird nun das Binding möglich.
Und natürlich wird jedes Binding nochmals ausgeführt (bzw. der passende Converter aufgerufen), bei welcher die Language vererbt wurde (was eigentlich überall der Fall ist).
Man sieht also auch: Die Anzeige wird nicht nicht bei Werteänderung aktualisiert, sondern auch bei “Language-Property” Änderung

Anbei mal ein ganz kleines Testprojekt, welches das Umschalten der Language zur Laufzeit anhand dem DateTime aufzeigt:
WpfCulture.zip

In Foren kommt oft die Frage: Mein C++/CLI Programm läuft nicht auf anderen Rechner! Was brauche ich damit es läuft?

Die Frage ist einfach zu beantworten, wenn wir davon ausgehen, dass das Programm mit VS2010 (Beitrag für VS2008 gibt es hier) erstellt wurde:

1. Zuerst wird das .NET Framework benötigt (da C++/CLI ja die CLR verwendet). Aktuell ist dies für VC2010 die Version 4.0:
   .NET 4.0 (Full download)

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:
   VC2010 (x86)
   In dem seltenen Fall, dass man die Application als x64 übersetzt hat benötigt man diese CRT-Version: VC2010 Runtime x64

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

PPS: Auch sollte man beachten, dass es oft keinen Sinn macht C++/CLI zu verwenden. Das ist wirklich nur für InterOp gedacht!

Ab sofort gibt es den aktualisierten SQL Server 2008 R2 Express zum konstenlos runterladen.
Eines der wichtigesten neuerung der Express Edition dürfte wohl die erhöhung des Datenabnk-Größe-Limits von 4 GB auf 10 GB sein
Hier der Link zur SQL 2008 R2 Express Startseite
http://www.microsoft.com/express/Database/

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

No comment:
Microsoft Responds to the Evolution of Communities

Ich bin schon länger ein Fan von Sharepoint und verwendet dies auch für mehrere interne Projekte.
Seit einigen Tagen ist jetzt auch der Nachfolger der “Sharepoint Services 3.0″ verfügbar (natürlich immer noch kostenlos). Aber natürlich mit einem neuen Namen:
Sharepoint Foundation 2010

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

Mit Server 2008 R2 Service Pack 1 wird es endlich eine Erweiterung des RDP (Remote Desktop Protocols) geben: 3D!

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

Vielen Anfänger, welche C/C++ lernen wollen, suchen sich nach einer kostenlosen Entwicklungsumgebung und stossen dann früher oder später auf die Visual Studio 2008/2010 Express Edition.

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

In Foren kommt oft die Frage: Mein C++/CLI Programm läuft nicht auf anderen Rechner! Was brauche ich damit es läuft?

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:
   Microsoft Visual C++ 2008 Service Pack 1 Redistributable Package MFC Security Update

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

Wer von Euch kennt das Problem: Der Kunde hat ein Absturz oder einen Hänger Deines Programmes. Das einzige was Du bekommst ist ein Dump-File (z.B. entweder via WER oder durch eigenes schreiben von MiniDumpWriteDump).
Jetzt beginnt für Dich das Problem:

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

Wer zufällig vom 9.11. bis 13.11. auf der TechEd Europe in Berlin ist, darf gerne mal im Technical Learning Center (TLC) an den Ask-the-Expert (ATE) booths vorbeischauen, wo ihr mich treffen könnt