Visual Studio
VA X für VS 2010 ist auf dem Weg
Visual Studio ohne Visual Assist ist wie Windows ohne SpeedCommander. Im Blog von Whole Tomato ist nun zu lesen, dass mit einer Version für Visual Studio 2010 in den nächsten ein bis zwei Wochen gerechnet werden kann.
Visual Studio 2010 Beta 2
Zugegeben, ich bin diesmal etwas später dran. Seit Dienstag können sich MSDN-Abonennten die Beta 2 von Visual Studio 2010 herunterladen. Am Mittwoch wurde der öffentliche Download bereitgestellt. Martin hat in seinem Blog die wichtigsten Neuerungen zusammengefasst.
Visual Studio 2010 (Beta 1) in VMWare
Wer sich die Beta 1 von Visual Studio 2010 in VMWare installiert, der sollte unbedingt die DirectX-Grafikoption für die VM deaktivieren. Ansonsten gibt es ein paar unschöne Effekte, für die Visual Studio 2010 wohl nichts kann.
Unsichtbare Hauptsymbolleiste:
Probleme bei der Menübedienung:
Fehlende Menüeinträge:
Fensterchaos nach Layoutänderungen:
Effizienter Programmieren mit Visual Studio
Der eine oder andere kennt vielleicht die vielen kleinen (insgesamt 382) Tips zu Visual Studio, die Sara Ford täglich in ihrem Weblog veröffentlicht hat. Im letzten Herbst hat sie 250 davon in einem Buch zusammengestellt, die deutsche Ausgabe ist mittlerweile auch erhältlich. Ich habe mir das Buch gerade bestellt. Auf der Couch macht das Lesen halt mehr Spaß als vor dem Rechner.
Erwähnenswert ist vielleicht noch, dass Sara Ford alle ihre Einkünfte aus dem Buchverkauf einem Stipendienfond zur Verfügung stellt, um Betroffene vom Wirbelsturm Katrina den Collegebesuch zu ermöglichen.
Symboldateien einzeln laden
Beim Debuggen von Memory-Dumps hat man meistens das Problem, dass die entsprechenden Windows-Symboldateien zum Snapshot des Anwenders nicht vorhanden sind. Letztlich muss eine Symboldatei immer genau zur jeweiligen Dll passen, damit der Debugger den Aufrufstack vernünftig anzeigen kann. Dank dem Microsoft-Symbolserver ist das aber kein großes Problem, der Debugger kann sich die passenden Symboldateien automatisch herunterladen.
Nachteilig ist, dass man keine Möglichkeit hat, die gewünschten Symboldateien auszuwählen. Startet man einen Dump mit aktiviertem Symbolserver, dann werden automatisch alle Symboldateien heruntergeladen, die zum jeweiligen Snapshot passen. Zudem lädt der Debugger auch noch die entsprechenden System-Dlls herunter, was natürlich entsprechend dauert.
Mit VS 2008 SP1 scheint Microsoft das Laden von Symboldateien erheblich vereinfacht zu haben. Gestern habe ich ein Kontextmenü entdeckt, das ich bisher noch nie gesehen hatte. Ich bin mir sicher, dass dieses Menü in der RTM-Version noch nicht enthalten war:
Nach Auswahl des Befehls wurde die passende Symboldatei für „kernel32.dll“ heruntergeladen und der Aufrufliste aktualisiert. Genial!
TFS: Warehouse-Aktualisierung
Die TfsWarehouse-Datenbank enthält alle wichtigen Daten, die für die Generierung und Anzeige von Berichten nötig sind. Die Informationen stammen aus den operationalen Datenbanken (z.B. Arbeitsaufgaben, Versionskontrolle), sie werden durch den Warehouse-Webservice in die TfsWarehouse-Datenbank übertragen. Der TFSServerScheduler-Dienst sorgt dafür, dass dies stündlich geschieht. Allerdings läuft der Dienst wie berichtet nur auf einem an eine Domäne angeschlossenen Server.
Als Abhilfe habe ich mir ein kleines Programm geschrieben, welches die Aktualisierung der TfsWarehouse-Datenbank durch den Webservice anstößt. In Verbindung mit der Windows-Aufgabenplanung kann dies je nach Bedarf stündlich, täglich oder in anderen gewünschten Abständen geschehen. Optimaler wäre natürlich ein eigener Dienst, aber so schwer wollte ich es mir dann auch nicht machen.
// ****************************************************************************
// ****** Implementation zu wWinMain ******
// ****************************************************************************
int APIENTRY wWinMain(HINSTANCE /*hInstance*/, HINSTANCE /*hPrevInstance*/, LPWSTR /*lpCmdLine*/, int /*nCmdShow*/)
{
// Internet-Session oeffnen
HINTERNET hSession = WinHttpOpen(NULL, WINHTTP_ACCESS_TYPE_NO_PROXY, NULL, NULL, 0);
if (NULL != hSession)
{
// Verbindung herstellen
HINTERNET hConnect = WinHttpConnect(hSession, L"localhost", 8080, 0);
if (NULL != hConnect)
{
// Anforderung erstellen
HINTERNET hRequest = WinHttpOpenRequest(hConnect, L"POST", L"/Warehouse/v1.0/warehousecontroller.asmx/Run", NULL, WINHTTP_NO_REFERER, WINHTTP_DEFAULT_ACCEPT_TYPES, 0);
if (NULL != hRequest)
{
// Anforderung senden
BOOL fResult = WinHttpSendRequest(hRequest, WINHTTP_NO_ADDITIONAL_HEADERS, 0, WINHTTP_NO_REQUEST_DATA, 0, 0, 0);
// Anforderung wurde gesendet
if (fResult && WinHttpReceiveResponse(hRequest, NULL))
{
// Antwort abfragen
char szResponse[2048] = { 0 }; DWORD dwBytesRead = 0;
WinHttpReadData(hRequest, szResponse, 2048, &dwBytesRead);
}
// Anforderung schliessen
WinHttpCloseHandle(hRequest);
}
// Verbindung schliessen
WinHttpCloseHandle(hConnect);
}
// Session freigeben
WinHttpCloseHandle(hSession);
}
// Ans kloar
return 0;
}
Es wird einfach nur eine Url aufgerufen und die Antwort abgefragt, auf eine Fehlerausgabe habe ich verzichtet. Das kompilierte Programm könnt ihr hier herunterladen.
MFC abgespeckt
Letzte Woche Montag ist das Service Pack 1 für Visual Studio 2008 erschienen. Wichtige Neuerungen für den C++-Entwickler sind sicherlich die Unterstützung von TR1 und das UI-Update für die MFC. Nach den Installationsproblemen mit dem im April veröffentlichten Feature Pack wollte ich eigentlich erst einmal die Erfahrungen anderer abwarten.
Daraus wurde dann doch nichts. Zu Testzwecken hatte ich mir ein VS 2008 in einer VM installiert und anschließend das SP1 eingespielt. Probleme gab es keine, die Microsoft-Entwickler haben aus dem Feature Pack-Dilemma gelernt und diesmal wieder ausreichend getestet.
Erfreulicherweise hat Microsoft auch das Konzept beibehalten, die bisherige MFC sowie die neuen UI-Klassen nicht zu verzahnen. Somit kann man die Einbindung der neuen Klassen durch Entfernen der entsprechenden Sektion im Makefile sehr einfach entfernen und die MFC weiter im bisherigen Umfang verwenden. Nach dem Löschen der nicht mehr benötigten Dateien hat man wieder ein schlankes und übersichtliches MFC-Verzeichnis.
Neben den neuen UI-Klassen gab es in der Standard-MFC nur kleinere Korrekturen. Die in afximpl.h definierten Konstanten CX_BORDER und CY_BORDER wurden nach AFX_CX_BORDER und AFX_CY_BORDER umbenannt. Bei einigen Zeigern fehlte bisher die Prüfung gegen NULL, das wurde mit dem SP1 auch behoben.
Nach den positiven Erfahrungen bei der VM-Installation habe ich das SP1 dann auch auf meinem Entwicklungsrechner eingespielt sowie C/C++-Laufzeit und MFC kompiliert. Die Anleitungen für die C/C++-Laufzeit sowie für die MFC sind weiter gültig, zusätzlich müssen für einen manifestlosen Einsatz die Linkerkommentare in appmodul.cpp
#pragma comment(linker, "/include:__forceMFCManifestRTM")
und crtdll.c
#pragma comment(linker, "/include:__forceCRTManifestRTM")
auskommentiert werden. Ansonsten beschwert sich der Linker beim Erstellen der CRT sowie beim Erstellen einer MFC-Anwendung über einen fehlenden Import. Bisher habe ich leider noch nicht herausgefunden, was diese beiden Linkerkommentare bewirken sollen. Die RTM-Version kam noch ohne diese aus.
Fehler 1603 bei der Installation von TFS 2008 SP1
Die Aktualisierung auf TFS 2008 SP1 wurde kurz vor Fertigstellung mit dem Fehler 1603 beendet. Beim Durchstöbern der Log-Dateien entdeckte ich folgende Zeilen:
Using workflow file from location exe.
Executing workflow ‚Unquiesce AT’…
Stopping Windows Service ‚W3SVC’…
Starting Windows Service ‚W3SVC’…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden.
Retrying…
Starting Windows Service ‚TFSServerScheduler’…
System.InvalidOperationException: Der Dienst TFSServerScheduler kann nicht auf dem Computer . gestartet werden. —> System.ComponentModel.Win32Exception: Der angegebene Dienst kann nicht gestartet werden. Er ist deaktiviert oder nicht mit aktivierten Ger„ten verbunden
— Ende der internen Ausnahmestapelberwachung —
Nach diesen Zeilen startete dann das Rollback.
Die Startprobleme mit TFSServerScheduler kenne ich schon seit der Installation des TFS. Dieser Dienst ist dafür verantwortlich, die Warehouse-Datenbanken zu aktualisieren, auf denen die verschiedenen generierten Reporte aufbauen. TFSServerScheduler ist abhängig vom Windows-Anmeldedienst (Netlogon), der sich nach dem Start auf normalen Servern und Arbeitsplatzrechnern aber gleich wieder beendet. Er ist der Meinung, dass seine Dienste nur beim Arbeiten in einer Domäne nötig sind. Um auf die Berichte nicht verzichten zu müssen, habe ich mir ein kleines Hilfsprogramm geschrieben. Dazu demnächst mehr.
Dummerweise lässt sich der TFS aber nicht direkt auf einem Domänencontroller (DC) installieren. Bis kurz vor der finalen Version von TFS 2005 war das wohl noch möglich, laut Berichten in diversen Foren soll das mit der nächsten Version (Rosario) auch wieder möglich sein. Allerdings habe ich keine Lust, mir bis dahin noch einen zweiten Server als DC einzurichten.
Das halb eingespielte Update hatte den TFS 2008 aber in einen undefinierten Status gebracht, Verbindungsversuche wurden mit folgendem Fehler abgelehnt:
TF31001: Team Foundation kann die Liste von Teamprojekten aus Team Foundation Server nicht abrufen. Team Foundation Server gab folgenden Fehler zurück: Fehler bei der Anforderung mit HTTP-Status 503: TF30059: Schwerwiegender Fehler beim Initialisieren des Webdiensts.
Was tun? Die Lösung bestand darin, auf meinem Entwicklungsrechner in einer VM einen Windows Server 2003 zu installieren und diesen als DC einzurichten. Nach dem Beitritt des Server zu dieser Domäne ließ sich auch der Windows-Anmeldedienst samt TFSServerScheduler starten und das Update lief fehlerfrei durch. Anschließend hat der Server die Domäne wieder verlassen und läuft nun wieder eigenständig.
Bin ich denn etwa der Einzige, der den TFS 2008 ohne Domäne betreibt?
TFS: Dateidatum beim Verzweigen erhalten
Beim Verzweigen von Projekten im TFS und anschließenden Abruf des neuen Projekts bekommen die Dateien immer das aktuelle Systemdatum als Datum der letzten Änderung verpasst. In SourceSafe war es noch möglich, beim Abruf zwischen dem Systemdatum, dem Datum des Eincheckens und dem Datum der letzten Änderung zu wählen. Im TFS habe ich diese Einstellung leider noch nicht gefunden, ich würde aber das Datum der letzten Änderung bevorzugen.
Als Workaround habe ich mir ein kleines Programm geschrieben, welches das Änderungsdatum eines Verzeichnisbaums auf einen anderen überträgt. Der Aufruf erfolgt über die Kommandozeile mit dem Befehl
SyncModified.exe <SourceDir> <TargetDir>
Das Quellverzeichnis wird inklusive den Unterverzeichnissen durchlaufen und das Datum der letzten Änderung einer jeden Datei in das Zielverzeichnis übernommen (sofern die Datei dort existiert). Ein eventuell gesetztes Schreibschutzattribut bleibt erhalten.
Das kleine Tool (76 KiB) könnt ihr hier herunterladen.
TF80042 beim Öffnen einer Abfrage mit Excel
Beim Versuch, eine Abfrage aus dem Team Explorer heraus mit Excel zu öffnen, erhielt ich anfangs die Fehlermeldung
—————————
Microsoft Visual Studio
—————————
TF80042: Das Dokument kann nicht geöffnet werden, weil Microsoft Excel 2003 oder höher oder eine der zugehörigen Komponenten nicht installiert ist. Weitere Informationen finden Sie im Team Foundation-Installationshandbuch.
—————————
OK
—————————
Google brachte mich dann dazu, mit Hilfe des Office-Setupprogramms die Excel-Funktionalität .NET-Programmierunterstützung nachzuinstallieren. Diese Einstellung ist standardmäßig deaktiviert. Nun lassen sich die Abfragen auch in Excel anzeigen.