Dieser Makro sollten in jedem Fall nicht entfernt werden, denn Sie dienen der Übernahme einiger Einstellungen aus der General-Seite für die C++ Projekte. Zum Beispiel werden die Einstellungen für Unicode und MBCS über den Makro %(PreprocessorDefinitions) in die allgemeinen Compiler-Einstellungen übernommen (die entsprechenden Defines sind _UNICODE; UNICODE; _MBCS ).
Erzeugt man eine DLL wird zusätzlich _WINDLL gesetzt.
Setzt man ATL Optionen in der General Seite wird auch über die %(PreprocessorDefinitions) _ATLDLL bzw. _ATL_STATIC_REGISTRY gesetzt oder zurückgesetzt.
Gleiches gilt, wenn die MFC als shared DLL verwendet wird. In diesem Fall wird der Define _AFXDLL zusätzlich gesetzt.

Löscht man also %(PreprocessorDefinitions) dann werden alle diese Einstellungen nicht mehr  korrekt übernommen.

Anmerkung:
Bei dem Linker Makro %(AdditionalDependencies) habe ich eine ähnliche Verwendung vermutet, konnte aber keine direkte Beziehung zur Seite General herstellen.

Obwohl es auch hier Einflüsse auf die Linkereinstellungen gibt bei Änderungen in den General-Einstellungen. Werden allerdings die MFC als zusätzliche Bibliothek ausgewählt werden die Standard-LIBs aus dem SDK komplett entfernt. Hier gibt die MFC Bibliothek selbst vor in welchen zusätzlichen Libs, des SDK gesucht werden soll über #pragma comment(lib,..).

Dito kann man es auf ZDNet lesen:
http://blogs.zdnet.com/microsoft/?p=2769

Ich freue mich schon drauf, ich hoffe es findet sich Zeit mal wirklich damit spielen zu können und um herauszufinden ob der Slogan “The new 10 is the next 6″ wirklich trägt…

Besonders wichtig ist das für mich immer mit den Tastatureinstellungen, die immer anpasse.

Was ich aber jetzt mit positivem Erstaunen feststellen konnte ist folgendes:
Man kann Einstellungen auch aus VS-2005 nach VS-2008 übertragen und umgekehrt

Die XML Struktur des Exportformates ist nicht versioniert. Man kann direkt Einstellungen aus VS-2005 austauschen. Ideal wenn man Legacy Projekte noch behandeln muss und beide Systeme parallel fährt.

Manch ein Entwickler wird von der folgenden Nachricht begrüßt, wenn er MSVSMON.EXE startet:

Visual Studio Remote Debugging Monitor will not be able to debug applications because the ‘Network access: Sharing and security model for local accounts’ local security policy option is set to ‘Guest only – local users authenticate as Guest’. This can be configured with the ‘Local Security Settings’ administration tool.
Do you want to continue?    (Use /noguestonlywarn to suppress this warning)

Nun auch keine Tragik. Dann kommen wir aber um einen Neustart nach Änderungen der Lokalen Richtlinien nicht herum. Aber man muss erst mal wissen was mit dieser Meldung gemeint ist, wenn man ein deutsches OS benutzt:

1. Systemsteuerung starten.
2. Leistung und Wartung -> Verwaltung -> Lokale Sicherheitsrichtlinie
3. In den Lokalen Sichereinstellungen auf
   Lokale Richlinien -> Sicherheitsoptionen
4. Dort dann Netzwerkzugriff: Modell für gemeinsame Nutzung und Sicherheitsmodell für lokale Knoten auswählen.
5. Umstellen auf: Klassisch – lokale Benutzer authentifizieren sich als sie selbst
6. Reboot

HTH
Siehe auch:
How to: Set Up Remote Debugging
How to debug on computers that are running Windows XP and that are in the same Workgroup in Visual Studio .NET or in Visual Studio 2005

Indem man mit der Maus rechts oben auf das rote X klickt… 

Nein Es geht auch (zum Glück) über die Tastatur. Mit Umschalt+Escape kann man jedes Tool Window sofort auf Hide setzen und schließen. Der entsprechende Makro Befehl lautet Window.CloseToolWindow.

Für mich das ultimative Mittel der Qualitätssicherung und die beste Waffe für die Jagd auf den gemeinen Software-Bug ist und bleibt Remote Debugging.

Remote Debugging ist seit es Visual Studio 2002 gibt so einfach geworden wie noch nie. Und seit es Visual Studio 2005 ist es noch einen Tick einfacher geworden. Einziger Wermuthstropfen: Remote Debugging ist erst ab der Professional Version verfügbar.
Um so erstaunlicher wie wenig Entwickler dieses Werkzeug einsetzen.

Nehmen wir einfach mal den Fall, wir haben auf einer Maschine einen Crash, oder wir haben einen Zustand, den wir sofort Debuggen wollen. Geht das On-the-fly?

JA

Wenn die Rechner in einer Domäne sind, gibt es meistens gar keine Probleme und man kann einfach wie folgt vorgehen. 

1. Wir kopieren die Datei MSVSMON.EXE auf den Rechner auf dem wir Debuggen wollen:
   “C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\Remote Debugger\x86\msvsmon.exe”
   Ja! Erstaunlich, mehr ist nicht notwendig.
2. Beim ersten Start erhalten wir eine Warnung, dass wir die Firewall von XP SP2 oder Vista noch freischalten müssen. Gesagt getan.
3. Nun wählen wir einfach die schnelle etwas unsichere Methode:
   Menü Tools -> Options
   In dem entsprechenden Dialog, wählen wir nun einfach:
   No Authentication (native only)
   Allow any user to Debug
   Port 4015 bleibt unverändert.
   Am Besten jetzt noch die Maximum idle time (seconds) von 900 auf was Brauchbares hoch setzen, sonst wird die Session einfach beendet nach 15 Minuten.
4. Ja Das wars. Nun einfach im Visual Studio Tools -> Attach to Process wählen (Strg+Alt+P)
   Transport: Remote (Native only with no authentication)
   Qualifier: <Name des PCs den es zu debuggen gilt, oder IP-Adresse>
   Refresh
5. WOW! Und schon sieht man seinen Prozess den man debuggen möchte.
6. Jetzt nur noch auswählen und Attach

So einfach geht es.
Wenn man die passenden PDB Dateien in Reichweite hat, kann man sofort Breakpoints setzen und am “lebenden Patienten” operieren, als nur “post-mortem” mit Crashdumps zu arbeiten.

Wie man gezielt auch die Projekteinstellungen nutzen kann, habe ich mir für einen späteren Artikel vorgemerkt.

Siehe auch:
How to: Set Up Remote Debugging

Eigentlich wünscht sich der Entwickler nichts mehr, als dass ein falscher Zugriff auf den Heap, sofort einen Break im Debugger auslöst. Die Methoden, die ich bisher gezeigt habe (AfxCheckMemory, _CrtCheckMemory, _CrtSetDbgFlag) können das nicht direkt , aber zumindest helfen sie den Fehler einzukreisen.

Ein unverzichtbarer Helfer, der sofort solch einen Break auslösen kann, ist der Application Verifier, den ich bereits in einem älteren Artikel als Freund und Helfer vorgestellt habe.

Seit Visual Studio 2005 kann man direkt Parameter für den Application Verifier im Projekt einstellen und auch direkt den Debug-Prozess mit dem Application Verifier starten (Umschalt+Alt+F5).
An den Standardeinstellungen im Projekt braucht man hier gar nichts zu ändern:
Conserve Memory - No
Protection Location - Je nach Testfall (man sollte mit beiden Einstellungen mal debuggen)
Alle anderen Einstellungen Verification Layers Settings - auf Enable

Mit dem Application Verifier lässt sich der so genannte Paged Heap nutzen, der Guard Pages anlegt hinter oder vor den allokierten Speicherbereichen (siehe auch GFLAGS.EXE). Der Vorteil: Man erhält sofort eine Access Violation, wenn man den Speicherbereich überschreitet.

Mein kleines Demoproramm

1
2
3
4
5
6
7
8
9
10
11
12
13

#include <windows.h>
#include <tchar.h>
#include <crtdbg.h>
int _tmain(int argc, _TCHAR* argv[])
{
  char *pCorrupt = new char[100];
  ZeroMemory(pCorrupt,106); // -- This will corrupt the heap
  char *pOther = new char[100];
  ZeroMemory(pOther,100);
  delete [] pOther;
  delete [] pCorrupt;
  return 0;
}

crashed mit der Nutzung des Application Verifiers sofort und man kann im Call Stack die Zeile 7 ausmachen.
Genial ist besonders, dass der Application Verifier auch mit der Release Version sofort die Zeile 7 als Ursache identifiziert. Gerade wenn man also nicht auf die Debug-CRT zurückgreifen kann, ist der Application Verifier ein super Hilfsmittel.

Der Nachteil: Die Guard Pages liegen nicht exakt und direkt hinter dem allokierten Bereich, sondern auf der nächsten Page Boundary. Deshalb crashed mein Sample auch nicht wenn man den Speicher um nur 1 Byte überschreitet.

Aber der Application Verifier ist zum Testen ein absolutes Muss, weil auch falsche Handles erkannt werden und auch der Lock Verfification Layer für die Qualitätssicherung einfach nützlich zum entwanzen sind. (siehe auch Application Verifier Einstellungen in der MSDN).

Hinweis

Auf Windows XP und Windows Server 2003 erhält man ohne administrative Rechte die folgende Fehlermeldung:

Access denied. You need administrative credentials to use Application Verifier on image <App_Name.exe> on machine <Machine_Name>. Contact your system administrator for assistance

Unter Windows Vista oder Windows Server 2008 erhält man die flogende Fehlermeldung wenn der Application Verifier nicht elevated gestartet wird:

Access denied. You need administrative credentials to use Application Verifier on image <App_Name.exe> on machine <Machine_Name> or per user verifier settings should be enabled by the administrator. Please refer to documentation for more information.

Durch einen simplen Eintrag in der Registry lässt sich aber auch als normaler Benutzer, ohne administrative Rechte, der Application Verifier nutzen, man erzeugt einen DWORD Eintrag in der Registry mit dem Wert 1
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manger\ImageExecutionOptions
Nach einem Reboot kann man nun einfach den Application Verifier auch non-elevated, als normaler Benutzer nutzen.

Um WinMerge für den Compare einzusetzen verwende ich die folgenden Parameter:

Program: C:\Programme\WinMerge\WinMergeU.exe
Arguments: /x /e /wl /ub /dl %6 /dr %7 %1 %2

Und folgende Parameter habe ich für den Merge eingestellt:

Program: C:\Programme\WinMerge\WinMergeU.exe
Arguments: /x /e /wl /ub /dl %6 /dr %7 %1 %2 %4

Hier eine Erklärung aus der Onlinehilfe von WinMerge für Befehlszeilenschalter, die ich aktuell verwende:

• /x closes WinMerge if opened files are identical (after information dialog is shown). This parameter is useful when WinMerge is used as an external compare application. It helps to faster process and/or ignore files which don’t have any differences. Note that this option does not apply when files become identical when merging/editing them.
• /e allows WinMerge to be closed with a single Esc keypress. This is useful when using WinMerge as an external compare application. WinMerge can act like an dialog which is easy and fast to close.
• /wl initially opens left side as read-only. Use this when you don’t want to change left-side items in compare.
• /ub tells WinMerge to not add both paths to MRU. External applications should not add paths to Open-dialog’s MRU lists.
• /dl adds a description for left side shown instead of folder / filename. This allows showing version number or label for compared items. Like “Version 1.0″ or “Work Copy”.
• /dr adds a description for right side shown instead of folder / filename. This allows showing version number or label for compared items. Like “Version 1.0″ or “Work Copy”.

Die entsprechenden % Platzhalter sind so durch Visual Studio vorbelegt:

• %1 = Original file
• %2 = Modified file
• %3 = Base file
• %4 = Merged file
• %5 = Diff options
• %6 = Original file label (label for %1 file)
• %7 = Modified file label (label for %2 file)
• %8 = Base file label (label for %3 file)
• %9 = Merged file label (label for %4 file)

Leider muss man für jeden Datentyp sowohl Compare als auch Merge einzeln einstellen. Eine Default-Einstellung habe ich nicht gefunden.

Es gibt einen schönen Blogeintrag von James Manning, der auch noch andere Diff-Tools behandelt:
http://blogs.msdn.com/jmanning/articles/535573.aspx
Wie man sieht habe ich die WinMerge Parameter jedoch angepasst.

Wenn man unter Vista einen Crashdump benötigt dann sucht man DRWTSN32.EXE unter Vista vergeblich. Für die Qualitätssicherung sind mir Minidumps immer extrem wichtig.

Es stellt sich die nette Frage: Wie kommt man von einem Kunden dann an einen informativen Minidump, wenn man keinen WER-Account hat, oder das Programm nicht signiert war, oder gar der WER Server diese Dumps nicht anfordert?

Unter Vista ist alles noch einfacher und schwieriger geworden. Vista speichert leider nicht grundsätzlich Minidumps, aber es legt für Crashs unter Problemberichte und Lösungen einen eigenen Eintrag an. Zu Crashs von WER registrierten Programme werden hier evtl. direkt Lösungen oder Updates angeboten. Und auch Crashdumps werden hier mit abgelegt, wenn sie erzeugt werden..

So ist es unter Vista aus:

1. Das WER System in Vista erzeugt normalerweise nur Minidumps für signierte Programme bzw. wenn der WER Server einen Crash abruft.
2. Um immer einen Minidump zu erhalten muss in der Registry der folgende Wert gesetzt werden:
   HKLM\SOFTWARE\Microsoft\Windows\Windows Error Reporting\ (DWORD)  mit Namen ForceQueue  erzeugen und auf 1 setzen.
3. Dumps werden im Benutzerverzeichnis unter C:\Users\TheUserName\AppData\Local\Temp und hier C:\ProgramData\Microsoft\Windows\WER\ReportQueue abgelegt und sind meistens gepackt. Sie erhalten die Endung *.mdmp.
4. Der Zugriff kann ganz einfach erfolgen mit Systemsteuerung -> System und Wartung -> Problemberichte und Lösungen -> Probleme anzeigen und überprüfen
5. Dort findet man das entsprechende Programm und die dazugehörigen entsprechenden Crashs.
6. Weitere Infos einfach über Details anzeigen lassen.
7. Wenn es einen Dump gibt, dann findet man hier wieder einen Eintrag Temporäre Kopie dieser Dateien anzeigen
8. Damit lässt sich der Explorer öffnen und man erhält Zugriff auf die gespeicherten Daten.
9. Diese kann man sich nun als Entwickler zusenden lassen.

Siehe auch:

• Andere Möglichkeiten werden auch in diesem KB-Artikel beschrieben: http://support.microsoft.com/kb/931673/en-us.
• Alle Einstellungen des Vista WER Systems sind hier beschrieben:
  http://msdn.microsoft.com/en-us/library/bb513638(VS.85).aspx

Teilweise hatte ich diese Prozesse in einen Pre- und Postbuild Step eingebaut. Leider verhält sich Visual Studio oft genug eigentümlich, es merkt nicht das abhängige Dateien während des Build Prozesses verändert werden.

Bei einer Umstellung meiner Projekte stellte ich fest, dass es weitaus einfacher ist für solche speziellen Vorgänge eigene kleine Projekte zu erzeugen vom Typ “Utility“.

In diesen Projekten kann man einfach Ein- und Ausgabedateien definieren und den Befehl, der dazu notwendig ist die Daten eben zu bearbeiten.
Das Ganze wird dann in eine Master Solution kombiniert mit den entsprechenden Abhängigkeiten. Das hat vor allem auch den großen Vorteil, das auch die Projekte parallel im Build durchlaufen werden können.

Utility Projekte sind für manche Aufgaben weitaus besser geeignet als Pre- und Postbuild Steps. Vor allem werden durch die Verwendung von Utility Projekten die einzelnen Vorgänge entzerrt und verständlicher.