Visual Studio
Visual C++ 2008 Feature Pack Beta
Gestern abend hat Microsoft die erste Beta vom Visual C++ 2008 Feature Pack veröffentlicht. Das Paket ist 303 MiB groß und erfordert zur Installation ein englisches Visual Studio 2008. Die dazugehörige Dokumentation ist etwas kleiner (3.40 MiB) und lässt sich auch ohne Installation betrachten.
Mit der Installation des Feature Packs werden die CRT- und MFC-Verzeichnisse aktualisiert. Es empfiehlt sich daher, vor der Installation eine Kopie des aktuellen VS 2008-Installationsverzeichnisses anzulegen, damit man nach der Installation bei Bedarf zwischen beiden Versionen hin- und herschalten kann. Wer nach der Installation einen schwerwiegenden Fehler mit der Meldung bekommt, dass keine VS 2008-Installation gefunden werden konnte, der sollte vor der Installation des Patches die Installations-DVD von VS 2008 einlegen. Eine Aufforderung dazu gibt es nämlich nicht.
Mit dem Visual C++ 2008 Feature Pack verwandelt sich die MFC zu einem Monstrum. Das atlmfc\include-Verzeichnis wächst von 152 Dateien auf 334 Dateien an und im atlmfc\mfc\src-Verzeichnis befinden sich nach dem Update 437 Dateien (vorher 261). Die zu verteilende mfc90(u).dll wächst von 1.10 MiB auf 3.57 MiB an, was die Größe des Redistributionspakets mal eben locker verdreifacht.
Nun zu den guten Nachrichten. Die normalen MFC-Dateien sind bisher (noch?) nicht von den neuen BCG-Dateien abhängig. Wenn man in atlmfc\mfc\src\makefile die Sektion CONTROLBARS entfernt und die neuen Exporte in den mfc90(ud).def-Dateien löscht, dann kann die MFC immer noch ohne die BCG-Dateien erstellt werden. Zudem muss aus der atlmfc\mfc\src\mfcdll.rc noch die Zeile #include „afxribbon.rc“ auskommentiert werden, damit die Office 2007-Grafiken nicht eingebunden werden. Wenn das auch in Zukunft so bleibt, dann kann ich damit leben.
VS 2008: Remote Debugger unter Windows 2000
Beim Versuch, auf einer Windows 2000-VM den Remote Debugger auf die finale Version zu aktualisieren, bekam ich folgende Meldung zu sehen:
Weniger schön, zumal der Remote Debugger der Beta 2 dieses Verhalten noch nicht kannte. Aber glücklicherweise ist das nur ein Problem des Installationsprogramms. Wer vorsichtig genug war, das DVD-Image der Beta 2 noch nicht zu entsorgen, der entpackt einfach beide Versionen von rdbgsetup.exe (jeweils zu finden unter Remote Debugger\x86), ersetzt die install.exe der RTM-Version durch die der Beta 2 und startet diese dann manuell. Voila, und schon kann man wieder unter Windows 2000 debuggen.
Endlich da
Im heise-Newsticker ist mir gestern diese brandaktuelle Flash-Werbung über den Weg gelaufen:
VS 2008: MFC selbst kompilieren
Gestern hatte ich darüber berichtet, wie man der WinSxS-Hölle entkommt und eine eigene Version der C/C++-Laufzeit kompiliert. Nun kompilieren wir uns noch eine MFC ohne Manifest und können in Zukunft die C/C++-Laufzeit sowie die MFC unseren Anwendungen beilegen, ohne uns mit Manifestproblemen herumquälen zu müssen.
1. Anpassen der Dateien
Die nötigen Änderungen an den MFC-Dateien halten sich in Grenzen. Zuerst schnappen wir uns die Datei atlmfc\include\MFCassem.h und kommentieren das Manifest ab Zeile 25 bis zum Ende aus. In atlmfc\include\afx.h ersetzen wir die Zeilen 81 bis 97 durch folgende:
#ifndef _UNICODE #ifdef _DEBUG #pragma comment(lib, "MyMfc90d.lib") #pragma comment(lib, "MyMfc90sd.lib") #else #pragma comment(lib, "MyMfc90.lib") #pragma comment(lib, "MyMfc90s.lib") #endif #else #ifdef _DEBUG #pragma comment(lib, "MyMfc90ud.lib") #pragma comment(lib, "MyMfc90sud.lib") #else #pragma comment(lib, "MyMfc90u.lib") #pragma comment(lib, "MyMfc90su.lib") #endif #endif
Damit legen wir fest, dass unsere Anwendungen dynamisch gegen die MyMfc90(u).dll gelinkt werden.
2. Vorbereitung der .DEF-Dateien
In atlmfc\src\mfc\intel und atlmfc\src\mfc\intel befinden sich jeweils vier .DEF-Dateien, deren Modulnamen ebenfalls angepasst werden müssen:
mfc90.def -> MyMfc90 mfc90d.def -> MyMfc90d mfc90u.def -> MyMfc90u mfc90ud.def -> MyMfc90ud
Im Gegensatz zur C/C++-Laufzeit werden aber nur die Modulnamen in den .def-Dateien angepasst, die Dateinamen selbst dürfen nicht geändert werden.
3. Anpassung des Makefiles
Die Änderung in der Datei atlmfc\src\atlmfc.mak beschränkt sich darauf, die Erstellung der statischen MFC sowie der WinForms-Komponenten auszuklammern. Dazu löschen wir in Zeile 123 die Einträge MFC_STATIC und MFCM_DLL.
4. Kompilieren
Nun kopieren wir unsere bereits erstellten Batchdateien mit den Umgebungsvariablen aus dem Ordner crt in den Ordner atlmfc\src. Zusätzlich erstellen wir in diesem Verzeichnis eine Datei makemfc_x86.bat mit dem Inhalt
nmake -f atlmfc.mak MFC LIBNAME=MyMfc90 PLATFORM=INTEL MP_BUILD=1
sowie makemfc_amd64.bat mit
nmake -f atlmfc.mak MFC LIBNAME=MyMfc90 PLATFORM=AMD64 MP_BUILD=1
Anschließend öffnen wir eine Eingabeaufforderung und starten
vcvars_x86.bat makemfc_x86.bat
sowie anschließend
vcvars_amd64.bat makemfc_amd64.bat
Nach ein paar Minuten sollte der Compiler seine Arbeit erledigt haben und wieder das Befehlsprompt erscheinen.
5. Kopieren der Lib-Dateien
Der letzte Schritt ist das Kopieren der lib-Dateien nach atlmfc\lib, damit der Linker diese später auch findet. Die Lib-Dateien für die 32-bit Version werden bei der MFC-Erstellung in atlmfc\lib\Intel abgelegt und müssen deshalb manuell nach atlmfc\lib kopiert werden. Die Lib-Dateien für die x64-Version landen dagegen direkt im richtigen Verzeichnis (atlmfc\lib\amd64).
Die MFC-Dlls finden wir in atlmfc\src\mfc\intel bzw. atlmfc\src\mfc\amd64. Zusammen mit den Dlls der C/C++-Laufzeit sowie den jeweiligen PDB-Dateien kopieren wir sie in einen Ordner, der in die PATH-Umgebungsvariable eingetragen wird. Somit ist sichergestellt, dass Visual Studio 2008 beim Debuggen auch alle nötigen Dateien findet.
6. Kontrolle
Zur Kontrolle erstellen wir uns ein Testprojekt und prüfen, ob gegen die richtigen Dateien gelinkt wird. Dazu lassen wir uns vom AppWizard eine einfache MFC-Anwendung erstellen und kompilieren diese. Mit Hilfe der Schnellansicht von SpeedCommander lässt sich leicht ermitteln, ob die Programmdatei an die richtigen Module gebunden wurden. Wenn es so ausschaut, dann ist alles in bester Ordnung:
Die gleiche Aktion führen wir noch einmal für die MyMfc90(ud).dll durch, diese sollten ebenfalls gegen die MyVcr90(d).dll gelinkt sein.
7. Letzte Worte
Zum Abschluss sei nochmals erwähnt, dass sich diese beiden Artikel wirklich nur an den nativen Entwickler richten, der vollständigen Einfluss auf die von ihm verwendeten Komponenten hat. Dazu gehört, dass alle Fremdkomponenten im Quellcode vorliegen und somit gegen die angepasste C/C++-Laufzeit bzw. die MFC kompiliert werden können. Verwendet man dagegen zusätzliche Managed Code-Erweiterungen oder fertige Libs/Dlls, die bereits gegen die originale MsVcr90.dll gelinkt sind, dann sollte man um die manifestlose Lösung einen großen Bogen machen.
VS 2008: C/C++-Laufzeit selbst kompilieren
Wer möchte, dass sich seine Anwendungen ohne Installation von einem USB-Stick starten lassen, der hat ab Visual Studio 2005 schlechte Karten. Bis einschließlich Visual Studio .NET 2003 konnte man die benötigten C/C++-Laufzeitbibliotheken sowie die MFC einfach so dazupacken, ab Visual Studio 2005 beharren diese Module nun auf einer separaten Installation in das WinSxS-Verzeichnis. Es gibt zwar auch die Möglichkeit, anwendungslokale Manifeste zu verwenden, aber das ist mir ehrlich gesagt viel zu umständlich. Die beste und vor allem stressfreiste Lösung für einen nativen Entwickler sind immer noch zwei Dlls (oder drei bei Verwendung der STL), die man einfach in das Anwendungsverzeichnis kopiert.
Der Aufwand dafür ist gar nicht so groß. Man muss lediglich die C/C++-Laufzeit sowie die MFC ohne Manifest kompilieren und hat dann alle Möglichkeiten, die man vor Visual Studio 2005 auch hatte. Man muss aber darauf achten, dass man keine Bibliotheken verwendet, die man nur als Binärversionen zur Verfügung hat und die bereits ein Manifest enthalten. Viele Entwickler schrecken aber vor dem Kompilieren zurück, daher möchte ich euch an dieser Stelle eine Schritt-für-Schritt-Anleitung aufzeigen. In diesem Artikel geht es erst einmal um die C/C++-Laufzeit, die MFC nehmen wir uns das nächste Mal vor.
Alle Änderungen spielen sich unterhalb des VC-Verzeichnisses ab, daher sind alle folgenden Pfadangaben relativ zum VC-Verzeichnis (VisualStudioInstallDir\VC).
1. Sicherung
Der erste Schritt ist die Sicherung der originalen Dateien. Bei mir hat es sich bewährt, im VC-Verzeichnis zwei neue Verzeichnisse !orig und !changed anzulegen. In das !orig-Verzeichnis werden zuerst die Verzeichnisse
- atlmfc
- crt
- include
- lib
kopiert, damit wir uns ungestört an den anderen Dateien vergehen können. So erhalten wir eine originale und eine angepasste Konfiguration, die sich dann schnell durch das Verschieben der vier Ordner austauschen lassen.
2. Anpassen der Dateien
Für eine manifestlose Laufzeit müssen wir erst einmal die Manifestdefinitionen entsorgen. Diese befinden sich in den Dateien crtdefs.h und use_ansi.h. Beide Dateien kommen doppelt vor, einmal in include und einmal in crt\src. In crt\src\crtdefs.h suchen wir die Zeile 118
#include <crtassem.h>
und kommentieren danach bis einschließlich Zeile 173 alles aus. Bitte unbedingt auf die einzelnen #endif-Kommentare achten, die ein einfaches /* */ erschweren. Bei include\crtdefs.h erfolgt das gleiche noch einmal, hier zwischen den Zeilen 93 und 147. Analog erfolgen die Änderungen auch in crt\use_ansi.h (Zeilen 59 bis 113) und include\use_ansi.h (Zeilen 53 bis 107).
3. Vorbereitung der .DEF-Dateien
Die .def-Dateien für die nötigen Exporte sind bereits im crt\src-Verzeichnis vorhanden, allerdings mit etwas kryptischen Namen. Wir benennen die Dateien wie folgt um:
sample_m.def -> msvcmrt.def sample_p.def -> msvcprt.def sample_u.def -> msvcurt.def sampld_m.def -> msvcmrtd.def sampld_p.def -> msvcprtd.def sampld_u.def -> msvcurtd.def
In den Verzeichnissen crt\src\intel und crt\src\amd64 befinden sich jeweils zwei weitere Dateien, die auch umbenannt werden müssen:
_sample_.def -> msvcrt.def _sampld_.def -> msvcrtd.def
Nun müssen wir uns vernünftigen Namen für die Laufzeit-Dlls ausdenken. Ganz wichtig ist, dass wir hier einen eigenen Namen wählen, um Komplikationen mit den originalen (MsVcr90.dll) sowie anderen angepasste Dateien zu vermeiden. Als Beispiel verwenden wir MyVcr90.dll, die Modulnamen in den Definitionsdateien werden nun mit einem Texteditor wie folgt angepasst:
msvcmrt.def: MyVcm90 msvcmrtd.def: MyVcm90d msvcprt.def: MyVcp90 msvcprtd.def: MyVcp90d msvcurt.def: MyVcm90 msvcurtd.def: MyVcm90d
Nun noch die vier Dateien aus den intel\amd64-Verzeichnissen:
msvcrt.def: MyVcr90 msvcrtd.def: MyVcr90d
Damit das Kompilieren der MFC später nicht mit einem Fehler beendet wird, ergänzen wir die beiden msvcrtd.def-Dateien noch um diese vier Zeilen:
_strdup_dbg _fullpath_dbg _wcsdup_dbg _wfullpath_dbg
MyVcr90.dll steht hier aber wirklich nur als Platzhalter, ihr solltet das nach dem ersten funktionierenden Testlauf durch euren Wunschnamen ersetzen.
4. Vorbereitung der Ressourcendateien
Nun müssen noch die Ressourcendateien in crt\src umbenannt
_sample_.rc -> MyVcr90.rc sample_m.rc -> MyVcm90.rc sample_p.rc -> MyVcp90.rc
und die Versionsinfos in diesen drei Dateien angepasst werden.
5. Anpassung des Makefiles
Jetzt fehlt eigentlich nur noch die Anpassung des Makefiles an unsere Modulnamen. Dazu öffnen wir die Datei crt\src\makefile mit einem Texteditor und ändern die Modulnamen wie folgt:
RETAIL_DLL_NAME=MyVcr90 RETAIL_LIB_NAME=msvcrt RETAIL_DLLCPP_NAME=MyVcp90 RETAIL_LIBCPP_NAME=msvcprt RETAIL_DLLMIXED_NAME=MyVcm90 RETAIL_LIBMIXED_NAME=msvcmrt RETAIL_LIBPURE_NAME=msvcurt RETAIL_PT_LIBMIXED_NAME=ptrustm RETAIL_PT_LIBPURE_NAME=ptrustu DEBUG_DLL_NAME=MyVcr90d DEBUG_LIB_NAME=msvcrtd DEBUG_DLLCPP_NAME=MyVcp90d DEBUG_LIBCPP_NAME=msvcprtd DEBUG_DLLMIXED_NAME=MyVcm90d DEBUG_LIBMIXED_NAME=msvcmrtd DEBUG_LIBPURE_NAME=msvcurtd DEBUG_PT_LIBMIXED_NAME=ptrustmd DEBUG_PT_LIBPURE_NAME=ptrustud RC_NAME=MyVcr90 RCCPP_NAME=MyVcp90 RCMIXED_NAME=MyVcm90
In der Datei crt\src\makefile.sub ersetzen wir in den Zeilen 106, 111 und 116 die Option -Wp64 durch -MP. -Wp64 wird seit Visual Studio 2008 nicht mehr unterstützt, bei aktiviertem Schalter wird das Kompilieren der CRT sonst abgebrochen. -MP sorgt bei Multicore-Prozessoren dafür, dass das Kompilieren wesentlich flotter abläuft.
6. Kompilieren
Jetzt sind endlich fast alle Vorbereitungen abgeschlossen und wir nähern uns langsam dem Kompilieren. Vorher müssen wir aber noch dafür sorgen, dass der Compiler auch alle Dateien findet. Dazu erstellen wir uns in crt\src zwei Batchdateien. Zuerst vcvars_x86.bat mit:
@ECHO OFF @SET PSDKINC=E:\Visual Studio.9\VC\PlatformSDK\include @SET PSDKLIB=E:\Visual Studio.9\VC\PlatformSDK\lib @SET PSDKBIN=E:\Visual Studio.9\VC\PlatformSDK\bin @SET VSCOMMON=E:\Visual Studio.9\Common7 @SET VCTOOLS=E:\Visual Studio.9\VC @SET VCTOOLSINC=$(PSDKINC) @SET LLP64=0 @echo Setting environment for using Microsoft Visual Studio 2008 x86 tools. @set PATH=%VCTOOLS%\BIN;%VCTOOLS%\BIN;%PSDKBIN%;%VSCOMMON%\IDE;%PATH%; @set INCLUDE=%VCTOOLS%\ATLMFC\INCLUDE;%VCTOOLS%\INCLUDE;%PSDKINC%;%INCLUDE% @set LIB=%VCTOOLS%\ATLMFC\LIB;%VCTOOLS%\LIB;%PSDKLIB%;%LIB%
und anschließend vcvars_amd64.bat mit:
@ECHO OFF @SET PSDKINC=E:\Visual Studio.9\VC\PlatformSDK\include @SET PSDKLIB=E:\Visual Studio.9\VC\PlatformSDK\lib @SET PSDKBIN=E:\Visual Studio.9\VC\PlatformSDK\bin @SET VSCOMMON=E:\Visual Studio.9\Common7 @SET VCTOOLS=E:\Visual Studio.9\VC @SET VCTOOLSINC=$(PSDKINC) @SET LLP64=2 @echo Setting environment for using Microsoft Visual Studio 2008 x64 cross tools. @set PATH=%VCTOOLS%\BIN\x86_amd64;%VCTOOLS%\BIN;%PSDKBIN%;%VSCOMMON%\IDE;%PATH%; @set INCLUDE=%VCTOOLS%\ATLMFC\INCLUDE;%VCTOOLS%\INCLUDE;%PSDKINC%;%INCLUDE% @set LIB=%VCTOOLS%\ATLMFC\LIB\amd64;%VCTOOLS%\LIB\amd64;%PSDKLIB%\x64;%LIB%
Die Pfade der Umgebungsvariablen müsst ihr an euer System anpassen. Der Übersichtlichkeit halber habe ich die Dateien aus dem Windows-SDK wie bei Visual Studio 2005 in das Unterverzeichnis PlatformSDK kopiert. Bei Visual Studio 2008 erfolgt die Installation der SDK-Headerdateien und Bibliotheksdateien normalerweise nach C:\Program Files\Microsoft SDKs\Windows\v6.0A.
Das war es auch schon mit den Vorbereitungen. Nun öffnen wir eine Eingabeaufforderung, wechseln in das Verzeichnis crt\src und geben zum Kompilieren der x86-Version
vcvars_x86.bat nmake
und für die x64-Version
vcvars_amd64.bat nmake
ein. Danach wird der Rechner jeweils ein wenig beschäftigt sein und die Laufzeitbibliotheken erstellen. Etwaige Warnungen können ignoriert werden, nur Fehler sollten keine auftreten. Wenn sich der Befehlsprompt wieder meldet, dann ist das Gröbste erledigt.
7. Kopieren der Lib-Dateien
Der letzte Schritt ist das Kopieren der erstellten Importbibliotheken aus den Verzeichnissen crt\src\build\intel bzw. crt\src\build\amd64 in das lib-bzw. lib\amd64-Verzeichnis. Da wir uns nur für die dynamischen Bibliotheken interessieren, reichen diese vollkommen aus:
msvcrt.lib msvcrtd.lib msvcprt.lib msvcprtd.lib
In den Buildverzeichnissen finden wir auch die angepassten Dlls MyVcr90(d).dll für die C-Laufzeit sowie MyVcp90(d).dll für die C++-Laufzeit (STL). Die ebenfalls erstellten MyVcm(d).dll enthalten die Laufzeit für verwalteten Code. Die hier vorgestellte Vorgehensweise ist aber wirklich nur für rein nativen Code gedacht, daher können wir die Vcm-Dlls links liegen lassen.
Das war’s auch schon, mit der MFC geht es dann morgen weiter. Im Vergleich mit der C/C++-Laufzeit wird das aber eher ein Kindergeburtstag.
Pimp my autoexp.dat
Beim Debuggen in Visual Studio 2008 stört mich, dass bei CString-Objekten nicht mehr sofort die entsprechende Zeichenkette als InfoTip angezeigt wird. Stattdessen muss man den InfoTip erst erweitern, das gleiche gilt auch für die Anzeige der Variablen im Watch-Fenster:
Das hat mich an die Existenz der autoexp.dat erinnert, die es schon seit Visual Studio 6 gibt. Diese kann man um eigene Ausdrücke ergänzen, so dass der Debugger die Werte von bestimmten Datentypen gleich anzeigt. Die autoexp.dat befindet sich unter <VSInstallDir\Common7\Packages\Debugger> und sie kann mit einem einfachen Texteditor bearbeitet werden. Fügt man in der Sektion [AutoExpand] die beiden Zeilen
ATL::CSimpleStringT<char,1> = m_pszData=<m_pszData,s> ATL::CSimpleStringT<wchar_t,1> = m_pszData=<m_pszData,su>
hinzu, dann sieht die Anzeige im Debugger gleich viel besser aus:
Beim Blättern in der autexp.dat sind mir auch die auskommentierten Zeilen
; see EEAddIn sample for how to use these ;_SYSTEMTIME=$ADDIN(EEAddIn.dll,AddIn_SystemTime) ;_FILETIME=$ADDIN(EEAddIn.dll,AddIn_FileTime)
aufgefallen. Google hat mich dann zum EEAddIn-Beispiel geführt, welches ich sogleich heruntergeladen und kompiliert habe. Der ersten Begeisterung folgte aber sogleich die Enttäuschung, denn es funktionierte nicht. Auch die explizite Angabe des Pfades oder das Anpassen der Funktionsnamen auf die wirklich exportierten Namen (_AddIn_SystemTime@28) wollte nicht helfen.
Wie debuggt man aber ein AddIn für den Debugger, welches nur geladen wird, wenn eine andere Anwendung gedebuggt wird? Ich habe mich für die universelle MessageBox-Methode entschieden, also an den wichtigen Stellen einfache MessageBox-Aufrufe eingebaut. Es zeigte sich, dass
// read system time from debuggee memory space
if (!pHelper->ReadDebuggeeMemoryEx(pHelper, pHelper>GetRealAddress(pHelper), sizeof(SysTime), &SysTime, &nGot))
return E_FAIL;
fehlschlug. Mein Bauch sagte mir, dass ReadDebuggeeMemoryEx anstatt eines BOOL-Wertes möglicherweise einen HRESULT-Wert zurückgibt. Nach der Änderung dieser Zeilen auf
// read system time from debuggee memory space
if (FAILED(pHelper->ReadDebuggeeMemoryEx(pHelper, pHelper->GetRealAddress(pHelper), sizeof(SysTime), &SysTime, &nGot)))
return E_FAIL;
wurde der Wert einer SYSTEMTIME-Variablen plötzlich wunschgemäß angezeigt:
Auch die FILETIME-Variable sieht nun wesentlich informativer aus:
Bei der Entwicklung eines Dateimanagers kommt man ja öfters mit FILETIME-Variablen in Berührung. Dank dem EEAddIn sieht man nun sofort den formatierten Wert, ohne dass man erst ein paar Zeilen für die Formatierung einfügen muss. So gut bin ich nämlich auch nicht im Kopfrechnen, dass ich aus den beiden DWORD-Werten der FILETIME-Struktur sofort auf das richtige Datum schließen kann.
VS 2008: Deutsche Version im Januar
In seinem Weblog hat Somasegar die Pläne für die lokalisierten Versionen von Visual Studio 2008 und .NET Framework 3.5 bekanntgegeben:
- Japanische Version im Dezember 2007
- Deutsche und französische Version im Januar 2008
- Weitere Versionen im Februar 2008
Download läuft
Seit heute vormittag ist Visual Studio 2008 verfügbar, der Weg zum Download war allerdings sehr schwierig. Am Nachmittag hatte ich arge Probleme, die Subscription Downloads zu Gesicht zu bekommen. Der MSDN-Server war wohl arg gestresst und lieferte immer den Fehler
Server Error in ‚/‘ Application.
The file ‚/home.aspx‘ has not been pre-compiled, and cannot be requested.
Am frühen Abend ging es dann wieder, allerdings tauchte Visual Studio 2008 Professional immer noch nicht in der Liste auf. Der Download kam mit dieser Adresse endlich näher (man muss sich hier vorher mit seiner LiveID anmelden), allerdings tat sich beim Klick auf die Links nicht viel. Der Grund war mein Popup-Blocker, aber darauf muss man auch erst mal kommen.
Nun lädt ein Akamai-Downloadmanager als ActiveX-Control das ISO-Image herunter. Den bisher gewohnten Weg über den FTM hätte ich mit Sicherheit besser gefunden.
Kontextmenü entschlackt
Dank dem genialen Tipp von Martin habe ich das Projekt-Kontextmenü von Visual Studio endlich mal ein wenig übersichtlicher gestalten können. Seit Visual Studio 2005 war mir dies mit knapp 30 Einträgen doch ein wenig zu voll, die Übersichtlichkeit leidet unter den vielen Einträgen enorm.
Nach dem Hinzufügen von zwei Untermenüs („Source Safe“ und „Advanced“) und dem Wegsortieren der entsprechenden Befehle sieht es nun bedeutend übersichtlicher aus. Hier das Untermenü mit der Quellcodeverwaltung:
Und so schaut das Menü mit den weniger benötigten Befehlen aus:
Warme Farben
In 15 Jahren Windows-Entwicklung habe ich in der IDE immer mit den Standardfarben gearbeitet, also dunkler Text auf hellem Hintergrund. Der weiße Fensterhintergrund war mir aber immer zu grell, daher war das erste nach einer Windows-Installation die Anpassung auf RGB(255, 251, 240). Nebenbei hatte das den Vorteil, dass man bei Zeichenoperationen gleich bemerkte, wenn man es mal vergessen hatte, die korrekte Hintergrundfarbe zu setzen. Der Nachteil waren die vielen HTML-Seiten im weltweiten Netz, deren Programmierer es wohl als überflüssig ansahen, eine weiße Hintergrundfarbe anzugeben.
Bei Damien Guard habe ich neulich ein Farbschema gesehen, das sehr angenehm aussah. An die Envy Code R VS-Schrift konnte ich mich nicht gewöhnen, mir ist sie (genau wie Consolas) etwas zu dünn. Nach einigen kleinen Anpassungen sieht das bei mir nun so aus:
Wer das auch mal ausprobieren möchte, der kann sich das Farbschema hier herunterladen. Die Installation in Visual Studio erfolgt über das Importieren von Einstellungen im Menü Tools.