Da freut man sich doch:

Thank you for being a great contributor to Microsoft Visual Studio 2005.

You have been nominated to receive the Award for Customer Excellence. This award recognizes your extraordinary contribution to the Visual Studio 2005 product and will be shipped to you without charge.

Trotzdem werde ich dem VC6 weiterhin treu bleiben und VS2005 nur für die 64bit-Entwicklung und für das verzeichnisübergreifende Suchen und Ersetzen von Text verwenden.

Pünktlich zum Weihnachtsfest gibt es auf der MSDN-Seite nun auch die deutsche Version von Visual Studio 2005. Leider wird (noch?) kein komplettes DVD-Image wie bei der englischen Version angeboten, stattdessen gibt es zwei CDs und die deutsche MSDN als zusätzliche DVD. Möglicherweise lassen sich die einzelnen ISOs aber per Handarbeit zusammenbringen.

Dazu wurde auch noch die Dezember CTP von Vista als 32- und 64bit-Version freigegeben.

So steht es in unregelmäßigen Abständen in der VS2005-Statuszeile, verbunden mit einer Prozessorauslastung von 100%. Nach fast jeder Änderung an einer Projekteinstellung im SpeedCommander-Arbeitsbereich mit über 20 Projekten scheint VS2005 die IntelliSense-Datenbank aktualisieren zu wollen. Auf meinem P4 mit Hyperthreading ist das nicht ganz so tragisch, da man dank HT recht flüssig weiterarbeiten kann. Der AMD64 hat hier aber große Probleme, das System wird merklich blockiert.

Im neuen MSDN-Forum habe ich nun eine zugegebenermaßen etwas radikale Lösung gefunden. Das Umbenennen der Datei feacp.dll im Verzeichnis VC\vcpackages beendet die ständige Aktualisierung. Für IntelliSense im VC verwende ich schon seit vielen Jahren Visual Assist, daher sollte die Deaktivierung des hauseigenen Features auch keine Nachteile mitbringen. Mal schauen, ob noch andere Nebenwirkungen eintreten.

Die Installation heute lief wie erhofft problemlos. Wer beim Installationsassistenten Visual J#, Visual Web Developer und bei Visual C#, Visual C++ und Visual Basic jeweils Smart Device Programmability abwählt, der wird mit der Nicht-Installation von

• .NET Compact Framework 1.0 SP3
• .NET Compact Framework 2.0
• Microsoft Visual J# 2.0 Redistributable Package
• SQL Server 2005 Mobile Edition
• Microsoft Device Emulator 1.0

belohnt.

Der Programmcode ist wohl schon länger eingefroren, das letzte Änderungsdatum der Installationsdateien ist auf den 23.09.2005 gesetzt. Bei der ATL und der MFC hat sich im Vergleich zur RC-Version kaum noch etwas geändert.

Die einzige Änderung in der ATL hat mir aber dann doch einiges Kopfzerbrechen beschert. In zwei MFC-losen Projekten nutze ich die ATL-Konvertierungsfunktionen zwischen Ansi und Unicode, dafür habe ich lediglich die Datei ‘atlconv.h’ eingebunden. In der finalen Version wurde nun die globale Variable g_pfnGetThreadACP nach ‘atltrace.cpp’ verschoben, so dass man nun auch ‘atlbase.h’ einbinden muss, damit die Referenz aufgelöst werden kann.

Der Fehler mit der Kommandozeile wurde auch behoben.

Auf der MSDN-Seite gibt es seit einigen Minuten die finale Version von Visual Studio 2005 zum Download. Momentan ist nur die Professional-Version gelistet, die anderen werden aber vermutlich auch noch folgen.

Ich bin mal gespannt, wann die Download-Server in die Knie gehen.

Ich musste heute leider die Erfahrung machen, dass das Erstellen von Projekten per Kommandozeile in Visual Studio 2005 RC plötzlich nicht mehr funktioniert. Nach dem Aufruf ertönt ein Hinweiston und folgende Meldung erscheint:

Microsoft (R) Visual Studio Version 8.0.50727.26.
Copyright (C) Microsoft Corp 1984-2005. All rights reserved.

The operation could not be completed. Unspecified error

Auf der MSDN-Feedback-Seite zu Visual Studio 2005 fand sich glücklicherweise die Bestätigung, dass es sich um einen bekannten Fehler handelt, der in der finalen Version behoben sein sollte.

Mit einem kleinen Workaround ließ sich VS 2005 wieder zum Arbeiten überreden. Ich habe einfach die Datei msenv.dll aus dem Verzeichnis Common7\IDE durch die gleichnamige Datei aus der August-CTP ersetzt. Die Kommandozeilenaufrufe laufen nun wieder wie erwartet durch und auch mit der IDE selbst lässt es sich arbeiten. Nebenwirkungen kann ich natürlich nicht ausschließen, aber da ich momentan fast nur noch die Kommandozeile benötige, kann ich damit ganz gut leben.

Auf der MSDN-Seite kann man seit gestern den Release Candidate von Visual Studio 2005 herunterladen. Zur Version selbst kann ich leider noch nichts sagen, da ich zum Testen momentan recht wenig Zeit habe und mit der August CTP auch sehr zufrieden bin.

Ein großes Produktivitätshemmnis in Visual Studio 2005 ist für mich das Suchen- und Ersetzen-Fenster. Im Gegensatz zu früheren Versionen wird dieses Fenster nun als normales Dokumentenfenster innerhalb der geöffneten Quelltextdateien angezeigt. Das Suchen und Ersetzen wird somit zur Qual, da man während der Eingabe des Suchstrings den Quelltext aus den Augen verliert.

Trotz des intensiven Durcharbeitens aller Einstellungsdialoge konnte ich keine Möglichkeit finden, wie man dieses Fenster deaktivieren und wieder den normalen Dialog verwenden kann. Beim Debuggen auf dem x64-Rechner blinzelte mich plötzlich der gewohnte Dialog an, ich fand zuerst keine Erklärung, warum auf dem einen Rechner das Suchfenster und auf dem anderen der Dialog angezeigt wurde. Zufällig klickte ich dann mit der rechten Maustaste auf die Titelzeile des Dialoges und fand die verzweifelt gesuchte Einstellung:

Seit zwei Wochen gibt es nun die Juli-CTP (Community Technology Preview) vom Visual Studio 2005. Im Gegensatz zu den von Uwe gemachten Erfahrungen hatte ich keine Probleme, diese Version auf XP und XP x64 zu installieren.

Microsoft hat nun endlich (nach meinem Bugreport) die x64-DEF-Dateien für die MFC beigelegt, so dass man die MFC jetzt auch selbst kompilieren kann. Im Prinzip ging das vorher zwar auch schon, ich musste mir dazu aber die x64-DEF-Dateien selbst zusammenfrickeln, was mich damals einen ganzen Tag Arbeit gekostet hatte.

Beim Kompilieren der CRT (C-Runtime) gibt es mit der neuen Version leider Probleme, Microsoft hat wieder vergessen, neue hinzugefügte Dateien auch in die Installation zu packen. Als Workaround kann man aber die CRT von der Juni-CTP verwenden, diese läuft ohne größere Probleme durch.

Wenn man im Eigenschaftenfenster eines Projekts (oder einer Datei) die Buildkonfiguration wechselt, dann wird leider immer wieder die Seite “Common Properties | References” angezeigt anstatt die zuvor aktive Seite. Bis zur Beta 2 hat alles noch korrekt funktioniert, laut Bugreport sollte dies in der nächsten Version gefixt sein.

In den letzten Tagen habe ich mir die aktuelle Community Technology Preview vom Visual Studio 2005 installiert und damit etwas Zeit verbracht. Trotz einiger immer noch existierender Produktivitätsbremsen macht das Arbeiten mit VS 2005 zusehends mehr Spaß. Verantwortlich dafür sind einige nette Funktionen:

1) Projekte werden parallel erzeugt

Projekte, die unabhängig voneinander sind, werden auf Mehrprozessor-Maschinen parallel kompiliert. Die Anzahl der zeitgleich erzeugten Projekte ist abhängig von der Anzahl der Prozessoren. Auf meinem P4 mit Hyperthreading gibt es zwei logische Prozessoren, damit werden also zwei Projekte nebeneinander kompiliert. Beim nächsten Rechnerupdate lohnt es sich also wirklich einmal, einen Blick auf die Xeon-Prozessoren zu werfen.

2) Visual Assist ist nun auch für Visual Studio 2005 verfügbar

Die letzten Builds von Visual Assist unterstützen nun endlich auch das Visual Studio 2005. Wenn man sich einmal an Visual Assist gewöhnt hat, dann kann man ohne kaum noch arbeiten und fühlt sich sehr verlassen.

3) Hervorragender Debugger

Der Debugger ist eines der Sahnestücke in VS 2005, das Betrachten von Variablen während des Debuggens ist ein Traum. Man zeigt nur noch mit der Maus auf die entsprechende Variable und der Debugger zeigt eine Liste mit den Eigenschaften. Zeigt man wieder auf ein Objekt, dann wird auch dieses aufgeklappt und dessen Eigenschaften werden angezeigt:

4) Automatisches Einfügen eines Manifests

Damit eine Anwendung unter XP auch im entsprechenden Design angezeigt wird, muss sie ein Manifest enthalten. Bisher hat man das Manifest als Entwickler immer in die Ressourcendatei eingebunden. VS 2005 führt nun einen neuen Linker-Schalter ein, der ein Manifest auf Wunsch automatisch in die Programmdatei aufnimmt. In einer normalen Anwendung hat das Manifest immer die ID “1″ , in einer Dll (z.B. einer Explorer-Erweiterung) dagegen die “2″. Der Linker kümmert sich automatisch um die richtige ID, die folgenden Zeilen reichen völlig aus.

Diese Zeilen habe ich in eine Header-Datei gesteckt, die ohnehin in jedem Projekt eingebunden wird und allgemeine Eigenschaften definiert, die für alle Projekte gelten. Entsprechend der jeweiligen Plattform wird immer gleich das korrekte Manifest eingebunden, man muss sich nun nicht mehr mit Manifesten in Ressourcen herumärgern.

#if _MSC_VER >= 1400
#ifdef _M_IX86
   #pragma comment(linker,"/manifestdependency:\"type='win32' "   \
        "name='Microsoft.Windows.Common-Controls' "                \
        "version='6.0.0.0' "                                       \
        "processorArchitecture='x86' "                             \
        "publicKeyToken='6595b64144ccf1df' "                       \
        "language='*'\"")
#endif

#ifdef _M_AMD64
    #pragma comment(linker,"/manifestdependency:\"type='win32' "   \
        "name='Microsoft.Windows.Common-Controls' "                \
        "version='6.0.0.0' "                                       \
        "processorArchitecture='amd64' "                           \
        "publicKeyToken='6595b64144ccf1df' "                       \
        "language='*'\"")
#endif

#ifdef _M_IA64
    #pragma comment(linker,"/manifestdependency:\"type='win32' "   \
        "name='Microsoft.Windows.Common-Controls' "                \
        "version='6.0.0.0' "                                       \
        "processorArchitecture='ia64' "                            \
        "publicKeyToken='6595b64144ccf1df' "                       \
        "language='*'\"")
#endif
#endif