Komfortabler Dateimanager mit vielen Funktionen

Visual Studio

Visual C++ 2008 Feature Pack Beta

By Sven on 08.01.2008 - 10:09 in MFC, Visual Studio 2008 with 7 Kommentare

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

By Sven on 05.12.2007 - 10:46 in Visual Studio 2008 with 1 Kommentar

Beim Versuch, auf einer Windows 2000-VM den Remote Debugger auf die finale Version zu aktualisieren, bekam ich folgende Meldung zu sehen:

Meldung unter Windows 2000

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

By Sven on 03.12.2007 - 10:22 in Visual Studio 2008 with 3 Kommentare

Im heise-Newsticker ist mir gestern diese brandaktuelle Flash-Werbung über den Weg gelaufen:

Visual Studio 2008 Beta 2

VS 2008: MFC selbst kompilieren

By Sven on 01.12.2007 - 11:02 in MFC, Visual Studio 2008 with 5 Kommentare

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:

Importe von Test.exe

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

By Sven on 30.11.2007 - 11:19 in C++/ATL, Visual Studio 2008 with Keine Kommentare

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

By Sven on 29.11.2007 - 12:24 in Visual Studio 2005, Visual Studio 2008 with Keine Kommentare

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:

Keine direkte Anzeige von CString

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:

Direkte Anzeige von CString

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:

Direkte Anzeige von SYSTEMTIME

Auch die FILETIME-Variable sieht nun wesentlich informativer aus:

Direkte Anzeige von FILETIME

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

By Sven on 27.11.2007 - 17:47 in Visual Studio 2008 with 3 Kommentare

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

By Sven on 19.11.2007 - 19:48 in Visual Studio 2008 with 10 Kommentare

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

By Sven on 12.11.2007 - 22:29 in Visual Studio 2005, Visual Studio 2008 with 2 Kommentare

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:

Kontextmenü mit Quellcodeverwaltung

Und so schaut das Menü mit den weniger benötigten Befehlen aus:

Kontextmenü mit unnötigen Befehlen

Warme Farben

By Sven on 12.11.2007 - 20:11 in Visual Studio 2005, Visual Studio 2008 with Keine Kommentare

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:

Farbschema Visual Studio

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.

Top