Komfortabler Dateimanager mit vielen Funktionen

Visual Studio

Visual Studio 2013 ist auch da

By Sven on 17.10.2013 - 14:25 in Visual Studio 2013 with Keine Kommentare

Zeitgleich mit Windows 8.1 hat Microsoft auch die finale Version von Visual Studio 2013 zum Download freigegeben.

Ich werde mir die neue Umgebung sicher mal in einer virtuellen Maschine anschauen. Zum produktiven Einsatz wird es aber nicht reichen. Weitaus interessanter sind da der neue Compiler und die MFC. Ich bin guter Hoffnung, dass sich beide wieder ohne großen Aufwand in Visual Studio 2008 integrieren lassen.

Multitouch, MFC 10 und das Kontextmenü

By Sven on 31.05.2011 - 16:30 in MFC, Visual Studio 2010 with 2 Kommentare

Ein Anwender, der SpeedCommander auf seinem Tablet-PC einsetzt, hatte mir geschrieben, dass dort die Anzeige des Kontextmenüs nicht wie erwartet funktioniert. Eigentlich sollte das Kontextmenü erscheinen, wenn man den Stift etwas länger gedrückt hält. In SpeedCommander tut sich da aber nichts.

Die Fehlersuche ergab, dass die Anzeige des Kontextmenüs bis zur Version 13.20 noch funktionierte und der Fehler erst ab der Version 13.30 auftrat. Ein Blick in die Versionsgeschichte zeigte aber, dass es zwischen diesen beiden Versionen keine Änderungen in der Listenansicht gab, die zu diesem Problem hätten führen können.

Mit der Version 13.30 erfolgte allerdings auch der Umstieg von der MFC 9 (SP1) von Visual Studio 2008 zur MFC 10 von Visual Studio 2010. Eigentlich sollte man erwarten, dass eine neue MFC-Version keine Verhaltensänderung nach sich zieht; zumindestens nicht, wenn man neue Funktionen nicht bewusst aktiviert. Die neue Multitouch-Unterstützung der MFC 10 ist hier aber eine Ausnahme, denn sie ändert die Funktionalität eines Fensters auch ohne explizite Verwendung der neuen Multitouch-Funktionen.

Die Ursache des Problems fand sich in der Verarbeitung der Nachricht WM_TABLET_QUERYSYSTEMGESTURESTATUS in der CWnd::OnTabletQuerySystemGestureStatus. Nach Konvertierung der Bildschirmkoordinaten in Koordinaten des Fensters wird die virtuelle Funktion CWnd::GetGestureStatus aufgerufen, die immer den Wert TABLET_DISABLE_PRESSANDHOLD zurückgibt. Die MFC 10 deaktiviert also für jedes von CWnd abgeleitete Fenster die Möglichkeit, das Kontextmenü der rechten Maustaste durch längeres Drücken des Stiftes oder Fingers anzuzeigen. Das ist unabhängig davon, ob die Multitouch-Funktionen verwendet werden oder nicht.

Die eleganteste Fehlerbehebung ist natürlich die Beseitigung der eigentlichen Ursache, indem die Rückgabe von CWnd::GetGestureStatus einfach auf 0 geändert wird. Nach einer Neuerstellung der MFC ist das Verhalten dann für alle Fenster wieder so, wie es in früheren MFC-Versionen war. Multitouch-Erweiterungen für bestimmte Fenster lassen sich trotzdem einbauen, die Funktion ist ja überschreibbar. Leider hat sich Microsoft mit der MFC 10 dafür entschieden, die entsprechenden Make- und Definitionsdateien nicht mehr auszuliefern. Sofern man sich die Dateien für eine Neuerstellung der MFC also nicht selbst zusammenbastelt, bleibt nur die Möglichkeit, die Funktion CWnd::GetGestureStatus in allen eigenen Ableitungen von CWnd zu überschreiben und den Wert 0 zurückzugeben:

ULONG CMyWnd::GetGestureStatus(__in CPoint /*ptTouch*/)
{
    return 0;
}

Entsprechend des Umfangs der eigenen Anwendung und der Anzahl der Fenster mit eigenem Kontextmenü ist das natürlich ziemlich aufwendig. Aber es ist leider auch der einzige Weg, wenn man auf Tablet-PCs mit dem Kontextmenü arbeiten möchte. Einfacher für alle Betroffenen wäre es wohl, wenn Microsoft die nächste MFC-Version entsprechend anpassen würde.

Nachträglicher Identitätswechsel in der TFS-Datenbank

By Sven on 13.04.2011 - 09:05 in TFS with 2 Kommentare

Mit der Aktualisierung von Team Foundation Server (TFS) 2008 auf 2010 im letzten Jahr war bei mir auch ein Wechsel des Server-Betriebssystems verbunden. Eine direkte Aktualisierung von 32-bit auf 64-bit ist nicht möglich, so blieb nur eine Neuinstallation. Bei dieser habe ich auch den Servernamen geändert.

Leider war mir damals nicht bewusst, dass man in diesem Fall mit TFSConfig Identities sofort nach der Installation auch die Identitäten in der TFS-Datenbank anpassen muss. Unterlässt man dies, dann leben die alten Benutzerzuordnungen weiter und es werden für den neuen Servernamen neue Zuordnungen angelegt. Die Auswirkungen zeigten sich dann gleich in den Arbeitsaufgaben (Work Items), bei denen aus dem Benutzer Sven der Benutzer SERVER-ALT\Sven wurde. Ein Speichern ist nur noch möglich, wenn die Arbeitsaufgabe dem neuen Benutzer zugeordnet wird, da SERVER-ALT\Sven keinen gültigen Benutzernamen mehr darstellt.

Nun ist es etwas mühselig, die Änderung des zugewiesenen Benutzers bei mehreren 100 Arbeitsaufgaben für jede Arbeitsaufgabe einzeln zu machen. Ein guter Helfer ist hier der angebotene Webzugriff über http://tfs-server:8080/tfs/web/ auf die Arbeitsaufgaben, mit dem sich Massenänderungen in einem Rutsch durchführen lassen.

Damit waren die größten Probleme des unterlassenen Identitätswechsel behoben. Der verbleibende Eintrag von SERVER-ALT\Sven für den Ersteller der Arbeitsaufgabe war nur ein Schönheitsfehler, an den man sich gewöhnen konnte bzw. musste, da dieser Wert schreibgeschützt ist und nicht geändert werden kann. Zum Problem wurde der Schönheitsfehler erst bei der Bearbeitung von Fehlern, die vor der Serverumstellung angelegt wurden. Beim Einchecken mit gleichzeitigem Abhaken der Arbeitsaufgabe kam die Fehlermeldung, dass einige Daten nicht gültig waren. Den Grund sieht man, wenn man in der Arbeitsaufgabe den Status von Aktiv auf Gelöst setzt. Dabei wird automatisch der Wert von Erstellt von (Created By) auf Zugewiesen an (Assigned To) übertragen. Aus dem Benutzer Sven wurde wieder SERVER-ALT\Sven, welcher das Speichern der Arbeitsaufgabe bei der Gültigkeitsprüfung verhindert.

Eine endgültige Lösung der Identitätsprobleme führt nur über einen manuellen Eingriff an der TFS-Datenbank. Die Benutzerdaten in den Arbeitsaufgaben werden in den Tabellen dbo.WorkItemsAre, dbo.WorkItemsWere und dbo.WorkItemsLatest gespeichert. Die für Erstellt von (Created By) zuständige Spalte trägt den Namen Fld33_Normalized. Die in den Tabellen abgelegte Kennung für den Benutzer bezieht sich auf die Tabelle dbo.Constants und verweist dort auf den entsprechenden Eintrag in der Spalte ConstID.

Die Aktualisierung der Benutzerkennung für Erstellt von (Created By) lässt sich mit einer einfachen SQL-Abfrage erledigen:

UPDATE [Tfs_Collection].[dbo].[WorkItemsAre]
SET [Fld33_Normalized] = 337
WHERE [Fld33_Normalized] = 2

UPDATE [Tfs_Collection].[dbo].[WorkItemsLatest]
SET [Fld33_Normalized] = 337
WHERE [Fld33_Normalized] = 2

UPDATE [Tfs_Collection].[dbo].[WorkItemsWere]
SET [Fld33_Normalized] = 337
WHERE [Fld33_Normalized] = 2

337 steht für die neue Kennung und 2 für die alte. Diese unterscheiden sich natürlich von Datenbank zu Datenbank. Der Datenbankname Tfs_Collection muss ebenfalls an das jeweilige System angepasst werden.

Bei dieser Gelegenheit kann man auch die Einträge von Geändert von (Changed By), Zugewiesen an (Assigned To), Aktiviert von (Activated By), Gelöst von (Resolved By) und Geschlossen von (Closed By) anpassen. Die entsprechenden Felder sind Fld9_Normalized, Fld24_Normalized, Fld10004Normalized, Fld10006_Normalized und Fld10009_Normalized. Das Feld PersonId scheint ebenfalls für die jeweilige Person zu stehen, dann auch hier wechselten die Kennungen mit dem Zeitpunkt der Umstellung. Damit wäre der der Identitätswechsel für die Arbeitsaufgaben schon erledigt. Sind mehrere Entwickler vorhanden, dann müssen die obigen Abläufe natürlich für jeden Entwickler durchgeführt werden.

Bleibt noch die Aktualisierung der Kennungen für die Quellcodeverwaltung und für die Bezeichnungen. Die entsprechenden Tabellen heißen dbo.tbl_ChangeSet und dbo.tbl_Label. Die hier verwendete Kennung unterscheiden sich aber von denen in den Arbeitsaufgaben, da sie einen kleinen Umweg über die dbo.tbl_Identity nimmt. Der Eintrag für den jeweiligen Benutzer in der Tabelle dbo.Contants enthält ein Feld TeamFoundationId, welches in dbo.tbl_Identity zur verwendeten Kennung in den beiden Tabellen führt. Die entsprechenden Anweisungen lauten:

UPDATE [Tfs_Collection].[dbo].[tbl_ChangeSet]
SET [CommitterId] = 26
WHERE [CommitterId] = 1

UPDATE [Tfs_Collection].[dbo].[tbl_ChangeSet]
SET [OwnerId] = 26
WHERE [OwnerId] = 1

UPDATE [Tfs_Collection].[dbo].[tbl_Label]
SET [OwnerId] = 26
WHERE [OwnerId] = 1

Damit sind innerhalb der Quellcodeverwaltung und bei den Arbeitsaufgaben alle Verweise von SERVER-ALT\Sven auf Sven geändert. Zu möglichen Änderungen in anderen Bereichen (Reporting, Build-Server, SharePoint) kann ich leider nichts sagen, da diese bei mir nicht im Einsatz sind.

Abschließend sei natürlich noch erwähnt, dass Änderungen an der TFS-Datenbank an den Verwaltungswerkzeugen vorbei nicht ungefährlich sind und nur unter größten Vorsichtsmaßnahmen durchgeführt werden sollten. Ein vorheriges Backup der Datenbank ist Pflicht!

Visual Studio 2010 kurz getestet

By Sven on 26.05.2010 - 11:05 in Visual Studio 2010 with 5 Kommentare

Nun hat die Neugier doch gesiegt und ich habe auf meinem Entwicklungsrechner Visual Studio 2010 installiert. Man kann sich ja nur mit ein paar gesammelten Erfahrungen für oder gegen eine Sache entscheiden.

Bei der Installation gab es nichts zu bemängeln, alles lief sauber durch. Auch die AddIns Visual Assist und Tabs Studio waren schnell eingerichtet. Auf Tabs Studio bin ich über einen Pingback zum EasyTabs-Beitrag gestoßen. Tabs Studio bietet die wichtigsten Funktionen von EasyTabs. Etwas nachteilig ist lediglich, dass die Leiste nicht auch unten angeordnet werden kann. Aber daran könnte man sich sicher gewöhnen.

Große Ernüchterung brachte der Aufruf der Online-Hilfe, zu der Martin schon einen treffenden Beitrag geschrieben hat. Keine Ahnung, was Microsoft sich da wieder mal gedacht hat, wenn überhaupt. Alles läuft im Browser ab und somit natürlich auch außerhalb der IDE. Vermutlich verwenden bei Microsoft alle Entwickler mehrere Bildschirme und müssen nie in der Hilfe suchen.

Bei der Anpassung von Menüs und Symbolleisten geht Microsoft neue innovative Wege. Symbolleisten können per Maus nur noch an der jeweiligen Andockposition hin- und hergeschoben werden. Das Wechseln der Positionen (z.B. vom oberen Fensterrand an den unteren) ist nur noch per Dialog möglich. Aber auch das Hinzufügen, Entfernen oder Verschieben von Symbolen oder Menüeinträgen funktioniert nur noch über ein Dialogfenster. Die Maus ist immerhin noch dafür da, die entsprechenden Schaltflächen im Dialog anzuklicken. Ich bin gespannt, ob sich dieses neue Bedienkonzept auch in anderen Anwendungen durchsetzt.

Über die Darstellungsqualität des Texteditors kann ich mich nicht beklagen. Alles wird sauber dargestellt, auch ohne die ClearType-Einstellungen anpassen zu müssen. Erheblich verschlechtert hat sich aber leider wieder einmal die Makro-Performance. Ich habe mir schon zu VC6-Zeiten ein paar Makros geschrieben, die auf Knopfdruck diverse Kommentarblöcke in Quelltextdateien einfügen. Im VC6-Editor waren die Blöcke quasi schon eingefügt, wenn man das jeweilige Tastenkürzel losgelassen hat. Der Editor von Visual Studio 2008 brauchte für die gleiche Aktion schon etwas über zwei Sekunden, was aber von Visual Studio 2010 mit über sechs Sekunden locker übertroffen wird.

Aufgrund der fensterlosen WPF-Oberfläche ist das Scrollen eines inaktiven Fensters per Mausrad mit Hilfe von KatMouse nicht mehr möglich. Man muss immer erst in das Fenster klicken, welches man durchblättern möchte. Die Bearbeitung der globalen VC-Verzeichnisse für Header- oder Bibliotheksdateien im Einstellungsdialog wurde wegen der Umstellung auf das MSBuild-System abgeschafft, stattdessen muss man diese nun in den Eigenschaftsseiten eines Projekts bearbeiten. Dazu wählt man im Menü Ansicht den Eigenschaften-Manager und öffnet jeweils eine Win32- und x64-Konfiguration:

Über den Befehl Eigenschaften des Kontextmenüs öffnet man den Einstellungsdialog und kann nun die Verzeichnisse anpassen:

Die aktualisierten Eigenschaften-Dateien werden in den lokalen Eigenschaften des Benutzers (C:\Users\<Benutzername>\AppData\Local\Microsoft\MSBuild\v4.0\Microsoft.Cpp.Win32.user.props bzw. Microsoft.Cpp.x64.user.props) abgelegt.

Zu dieser offiziellen Methode gibt es noch eine Alternative, mit der man die VC-Verzeichnisse systemglobal für alle Anwender ändern kann. Dazu öffnet man die beiden Dateien C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\Win32\PlatformToolsets\v100\Microsoft.Cpp.Win32.v100.props und C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Platforms\x64\PlatformToolsets\v100\Microsoft.Cpp.x64.v100.props und editiert die Pfade direkt. SpeedEdit kann auch Dateien in UAC-geschützten Verzeichnissen bearbeiten, bei Verwendung eines anderen Editors muss man die Dateien vor der Änderung erst in ein UAC-freies Verzeichnis kopieren und anschließend wieder zurückspielen.

Eine Konstante beim Erscheinen einer neuen Visual Studio-Version ist die Umstellung auf neue Projekt- und Arbeitsbereichsdateien. Die Konvertierung geschieht automatisch beim Öffnen eines alten Projekts oder eines Arbeitsbereichs. Dabei kann es passieren, dass Meldungen mit der Kennung MSB8012 angezeigt werden:

MSB8012: $(TargetName) (‘CxArj’) does not match the Linker’s OutputFile property value ‘..\..\lib\CxArj61u.dll’ (‘CxArj61u’) in project configuration ‘Release|Win32’. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetName) property value matches the value specified in %(Link.OutputFile).

MSB8012: $(TargetPath) (‘D:\Visual C++\Dev\Libraries\CxArchiver\CxArj\.\objs\Release\CxArj.dll’) does not match the Linker’s OutputFile property value ‘..\..\lib\CxArj61u.dll’ (‘D:\Visual C++\Dev\lib\CxArj61u.dll’) in project configuration ‘Release|Win32’. This may cause your project to build incorrectly. To correct this, please make sure that $(TargetPath) property value matches the value specified in %(Link.OutputFile).

Das passiert, wenn im Projekt eine Ausgabedatei festgelegt wird, die sich vom Projektnamen selbst unterscheidet oder der Ausgabepfad für die Datei nicht dem eingestellten Ausgabeverzeichnis für das Projekt entspricht. Ich vermute mal, dass dieses gar nicht mal so selten vorkommt, da Zieldateien in der Debugversion häufig durch ein abschließendes “d” bzw. bei Erstellung von Ansi-/Unicode-Projekten durch ein zusätzliches “u” für die Unicode-Variante gekennzeichnet werden. Bei mir ist es z.B. so, dass alle Dlls in einem gemeinsamen Zielverzeichnis erstellt werden. Da ich aber nicht möchte, dass sich in diesem Verzeichnis auch alle .exp- und .lib-Dateien dieser Dlls tummeln, unterscheidet sich das Ausgabeverzeichnis des Projekts vom Zielverzeichnis der Dlls.

Die gleichen Warnungen werden anschließend auch beim Erstellen des Projekts angezeigt. Zur Auflösung des Konflikts wird empfohlen, den Projektnamen in den allgemeinen Konfigurationseigenschaften anzupassen. In Visual Studio 2010 gibt es dafür ein neues Feld für die Anpassung von $(TargetName). Allerdings muss man diese Änderung dann auch für alle Projekte in allen Konfigurationen durchführen. Wer also 100 Projekte mit jeweils vier Konfigurationen hat (Release/Debug für Win32/x64), darf unter Umständen 400x mal den Zielnamen anpassen, wenn der Name der Ausgabedatei nicht dem Projektnamen entspricht.

Allerdings ist es mir nicht gelungen, die zweite Warnung zum $(TargetPath) abzustellen, ohne das Ausgabeverzeichnis dem Zielverzeichnis gleichzusetzen. Fans der Holzhammer-Methode öffnen einfach die Datei C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\Microsoft.CppBuild.targets und entfernen in Zeile 982 den Text DoLinkOutputFilesMatch. Nachteilig ist dabei aber, dass die Variable $(TargetPath) dann nicht mehr der tatsächlichen Ausgabedatei entspricht, sondern stattdessen auf das in den Projekteigenschaften definierte Ausgabeverzeichnis zeigt. Wichtig ist das bei selbstdefinierten Build-Ereignissen, die man entsprechend anpassen muss, wenn man die Zieldatei nicht im Ausgabeverzeichnis ablegen möchte.

Nach der Konvertierung eines Arbeitsbereichs kann dieser mit Visual Studio 2008 nicht mehr geöffnet werden, wenigstens wird eine Sicherungsdatei angelegt. Will man mit beiden Versionen weiterarbeiten, dann muss man Arbeitsbereiche und Projektdateien doppelt pflegen. Vorsicht aber beim Einchecken in den TFS, da alle alten Projektdateien nach der Konvertierung automatisch aus der Quellcodeverwaltung gelöscht werden.

Mir persönlich fällt es sehr schwer, wesentliche Gründe zu finden, die für einen Umstieg auf Visual Studio 2010 sprechen. .NET 4 brauche ich nicht, die Hilfe-Funktion ist praktisch nicht mehr vorhanden und der neue historische Debugger funktioniert sowieso nur mit .NET-Code. Das erheblich verbesserte IntelliSense bringt mir auch keine Vorteile, da Visual Assist hier schon seit Jahren um Klassen besser ist. Die für einen C++-Entwickler wichtigen Neuerungen (Compiler, C/C++-Laufzeit und MFC) lassen sich zudem sehr einfach in Visual Studio 2008 einbinden.

Fazit: Bis zum Erscheinen von Visual Studio 2012 geht es erst einmal mit Visual Studio 2008 R2 weiter.

Aktualisierung auf TFS 2010

By Sven on 25.05.2010 - 18:30 in TFS with 2 Kommentare

Ich habe lange überlegt, ob ich den Team Foundation Server auf die neue Version aktualisiere. Aufgrund meines vorläufigen Verbleibs bei Visual Studio 2008 R2 ist das Upgrade eigentlich nicht notwendig. Allerdings versprühen die geringeren Softwareanforderungen einen gewissen Charme. Für die Installation von TFS 2008 war eine Windows-Serverversion notwendig, dazu kamen noch ein SQL-Server mit Berichts- und Analysefunktion sowie SharePoint. Das SP1 ließ sich nur einspielen, wenn der TFS-Server an einen Domänencontroller angemeldet war, allerdings durfte er selbst nicht auf einem solchen installiert werden. Ich musste also temporär einen Domänencontroller in einer VM installieren und vor dem SP1-Update den Server in die Domäne einklinken. Nach dem Update konnte die Verbindung wieder gelöst werden. Einfach sieht anders aus.

TFS 2010 ist hier deutlich anspruchsloser. Er lässt sich auch auf einem Client-Betriebssystem installieren und begnügt sich mit der Express-Variante vom SQL Server. Diese wird auf Wunsch auch während der Einrichtung des TFS installiert, einfacher geht es nicht. Zudem reizte mich auch eine Aktualisierung des Betriebssystems auf Windows 7 oder Windows Server 2008 R2, die eine bessere Zusammenarbeit mit Windows 7-Clients versprechen. TFS 2008 läuft bei mir noch auf einem Windows Server 2003 R2.

Die Festplatte meines Servers enthält bereits zwei primäre Partitionen mit jeweils 30 GB, einer testweisen Aktualisierung stand also nichts im Weg. Nach der Sicherung der aktuellen TFS-Datenbanken mit DBSave wurde auf der freien Partition Windows Server 2008 R2 eingespielt, anschließend folgte noch der gerade veröffentlichte SQL Server 2008 R2 sowie der TFS 2010. Nach der Rücksicherung der Datenbanken wurde TFS 2010 mit Hilfe der Team Foundation-Administratorkonsole über die Upgradefunktion eingerichtet:

Berichtsfunktion und SharePoint habe ich deaktiviert, da die beiden Sachen in den letzten zwei Jahren kaum bzw. gar nicht benötigt wurden. Wer mag, der kann im achten Schritt noch den vorgegebenen Namen für die Standardkollektion ändern, dies ist später nicht mehr möglich.

Auf dem letzten Screenshot ist zu sehen, dass bei der Installation auch gleich der Webzugriff eingerichtet wurde. Dafür musste im TFS 2008 noch eine zusätzliche Software eingespielt werden.

Anwender von Visual Studio 2008 müssen nun noch das Update für die Aufwärtskompatibilität von Visual Studio Team System 2008 Service Pack 1 mit Team Foundation Server 2010 installieren. Beim Verbinden mit einem TFS 2010-Server muss im Verbindungsdialog die vollständige Adresse http://server:8080/tfs angegeben werden.

Ein kleines Problem hatte ich mit dem alten Arbeitsbereich, der zwar übernommen aber in Visual Studio 2008 nicht erkannt wurde. Löschen und Neuanlegen schafften Abhilfe. An dieser Stelle noch der Hinweis, dass man zur Sicherheit vor der Aktualisierung möglichst alle Dateien einchecken sollte.

Deutsche Testversionen von Visual Studio 2010

By Sven on 29.04.2010 - 11:05 in Visual Studio 2010 with Keine Kommentare

Microsoft hat nun auch die deutschen Testversionen von Visual Studio 2010 zum Download bereitgestellt. Die Testzeit beträgt 30 Tage und kann nach einer Registrierung auf 90 Tage verlängert werden. Hier die Download-Links zu den verschiedenen Versionen (ISO):

Visual Studio 2008 R2

By Sven on 14.04.2010 - 13:45 in Visual Studio 2008, Visual Studio 2010 with 14 Kommentare

Heute gibt es einen Rezeptvorschlag für Visual Studio 2008 R2. Folgende Zutaten werden benötigt:

  • 1x installiertes Visual Studio 2008 (System 1)
  • 1x installiertes Visual Studio 2010 (System 2, vorzugsweise in einer VM)

Vorgehensweise:

  • Installation von .NET 4.0 auf System 1 (befindet sich auf der VS2010-ISO unter WCU\dotNetFramework)
  • Kopieren der Release/Debug-Laufzeitbibliotheken (CRT/MFC) in die 32/64-bit Systemverzeichnisse auf System 1 (zu finden unter %VS2010DIR%\VC\redist)
  • Kopieren der Symboldateien für CRT/MFC von System 2 nach System 1 (zu finden im Windows-Verzeichnis unter symbols\dll)
  • Verschieben der Ordner atlmfc, bin, crt, include und lib aus %VS2008DIR%\VC nach %VS2008DIR%\VC\!VC9
  • Kopieren der Ordner atlmfc, bin, crt, include und lib aus %VS2010DIR%\VC nach %VS2008DIR%\VC
  • Kopieren der Dateien mspdbsrv.exemspdb100.dllmspdbcore.dll und msobj100.dll aus %VS2010DIR%\Common7\IDE nach %VS2008DIR%\VC\bin

Das Ergebnis ist ein Visual Studio 2008 mit neuem Compiler/Linker sowie den aktuellen Versionen von CRT/MFC. Durch Austauschen der Ordner atlmfc, bin, crt, include und lib kann man jederzeit zwischen originaler und angepasster Version wechseln. Zu beachten ist noch, dass man die Header-/Bibliotheksdateien aus dem Windows 7-SDK verwendet (bzw. die Dateien, die von Visual Studio 2010 installiert wurden).

Eine Gewährleistung für die fehlerfreie Funktionalität wird selbstverständlich ausgeschlossen. Bisher konnte ich aber noch keine Einschränkungen feststellen.

Falsche Zielgruppe

By Sven on 13.04.2010 - 10:50 in Visual Studio 2010 with 4 Kommentare

Eine der spannenden neuen Funktionen in Visual Studio 2010 ist der historische Debugger, der mittlerweile zu IntelliTrace umbenannt wurde. Damit werden während der Programmausführung automatisch bestimmte Zustände protokolliert, die dann vom Entwickler nachträglich angesprungen werden können. Dies kann dann in beliebiger Reihenfolge passieren, also auch zurück bzw. kreuz und quer. Mehr Informationen dazu gibt es im Blog von Ian Huff.

Diese Funktion ist aber der Ultimate Edition von Visual Studio 2010 vorbehalten, die Microsoft als Einzelplatzversion inklusive MSDN für 12739 Euro anbietet. Da schluckt man schon einmal etwas. Positiv ist allerdings, dass IntelliTrace nur mit Managed Code funktioniert (also .NET) und nicht mit nativem Code (C++). Da kommt man wenigstens nicht in Versuchung.

This is really cool!

By Sven on 12.04.2010 - 19:00 in Visual Studio 2010 with 1 Kommentar

Die Begeisterung bei der Vorstellung von Visual Studio 2010 war überall zu spüren:

Begeisterung

Die finale englische Version von Visual Studio 2010 gibt es bereits auf MSDN.

Licht und Schatten

By Sven on 16.02.2010 - 12:40 in Visual Studio 2010 with 15 Kommentare

Vor einer Woche hat Microsoft den Veröffentlichungskandidaten von Visual Studio 2010 zum Download freigegeben. Ursprünglich war ja für Mitte Februar schon die finale Version angekündigt. Aufgrund der doch recht schwachen Performance der Beta 2 hat man sich aber für eine kurze Verschiebung entschieden und möchte mit einer RC-Version sicherstellen, dass alle Probleme behoben sind.

IDE und Editor

Alle bisherigen Visual Studio-Entwicklungsumgebungen waren weitgehend in nativem Code geschrieben. Mit Visual Studio 2010 ändert sich das jetzt grundlegend, die neue IDE setzt größtenteils auf Windows Presentation Foundation (auch bekannt unter WPF) auf. Das schließt auch den Texteditor ein.

Beim ersten Bearbeiten einer Quellcodedatei kam mir die Schrift etwas blass vor. Die Farbeinstellungen von Visual Studio 2008 wurden beim ersten Start übernommen, so dass es eigentlich keine Unterschiede geben sollte. Auch ein Vergleich der Farbeinstellung im Einstellungsdialog zeigte, dass die Werte für die Textfarbe gleich sind (schwarz). Hier mal ein Screenshot mit beiden Darstellungen, die obere Hälfte zeigt VS 2010 und die untere VS 2008:

Editor in VS 2010/2008

Ich weiß nicht, wie das andere empfinden – mir geht es auf die Augen.

Durch die Umstellung auf WPF ändert sich auch die gesamte Fensterstruktur in der IDE, da eine WPF-Anwendung weitgehend fensterlos daherkommt. Das werden einige AddIn-Entwickler zu spüren bekommen. Einer davon bin ich, mein geliebtes EasyTabs funktioniert nicht mehr und müsste neu geschrieben werden.

Class Wizard

Mit der neuen Version feiert ein Urgestein der VC-IDEs seine Auferstehung – der Class Wizard ist zurück. Die Umsetzung des Assistenten ist auf den ersten Blick gut gelungen, sie kommt für mich aber um einige Jahre zu spät. Mittlerweile habe ich mich nämlich daran gewöhnt, Überschreibungen und Bearbeitungsfunktionen für Nachrichten selbst im Editor einzugeben. So kann man die Funktionen gleich an der richtigen Stelle eintragen, wenn man eine gewisse Übersicht bevorzugt. Der Class Wizard hängt dagegen alles nacheinander als öffentliche Funktionen am Ende der Klassendefinition an. Hut ab, wer da am Ende noch den Überblick über die Klasse hat.

Sprache und Bibliotheken

An der C++-Sprachfront hat sich einiges getan. Der neue Compiler kann mit Lambda Expressions umgehen und  kennt Rvalue-Referenzen. Mit dem auto-Schlüsselwort erspart man sich die eine oder andere Typendeklaration. Im Moment habe ich noch keine Ahnung, was sich damit alles anstellen lässt. Bisher habe ich mich bei der Verwendung der C++-Standardbibliothek (STL) immer sehr zurückgehalten.

Auch bei der C/C++-Laufzeit und der ATL/MFC gibt es eine Menge Neuerungen. Die wohl wichtigste in der C++-Laufzeit ist die Concurrency Runtime, eine Klassenbibliothek, die das Erstellen von Multicore-Anwendungen erleichtern soll. Die neue MFC bietet direkte Unterstützung der Taskbar von Windows 7, inklusive Taskbar-Miniaturansichten für MDI-Anwendungen. Der schon in Windows Vista eingeführte Restart-Manager zieht endlich in die MFC ein. Eingebaut ist auch eine Unterstützung für Windows 7 Multitouch.

Verteilung der Dlls

Eine wesentliche Änderung betrifft die Verteilung der C/C++-Laufzeit und der MFC. Bis einschließlich Visual Studio 2003 wurden die Dlls immer nur in das Systemverzeichnis kopiert. Ab und zu sorgte das für Ärger, weil einige Softwareanbieter nicht mit Versionsinformationen umgehen konnten und bei der Installation auch mal eine neuere Version einer Dll mit ihren alten Version überschrieben. Das alles ist auch unter dem Namen Dll-Hölle bekannt.

Windows XP versprach Abhilfe und führte die Side-by-Side Manifeste ein. Jede Dll-Version wurde nun mit einem Manifest versehen und im WinSxS-Verzeichnis abgelegt. Der Anwendung wurde bei der Erstellung die benötigten Dlls eingeimpft. Ab Visual Studio 2005 wurden nun auch die C/C++-Laufzeit und die MFC nach diesem Schema verteilt. Doch die Praxis war nicht so gut wie die Theorie. Die Dlls mussten zwingend in das WinSxS-Verzeichnis installiert werden, portable Anwendungen waren nur unter erschwerten Bedingungen möglich. Besonders kritisch war es auch, wenn man versehentlich ein im DEBUG-Modus kompiliertes Modul in eine Release-Anwendung aufgenommen hatte. Der Windows-Programmlader beschwerte sich dann über eine fehlerhafte Anwendungskonfiguration und meinte damit eigentlich die fehlende C/C++-Laufzeit in der Debug-Version.

Diese Probleme sind anscheinend auch bei Microsoft nicht spurlos vorbeigegangen. Mit Visual Studio 2010 lässt man die Side-by-Side Manifeste wieder links liegen und kehrt in die Dll-Hölle zurück. Vermutlich ist dies das kleinere Übel, mir kann es nur recht sein.

Erstellung der MFC

Seit Visual C++ 1.5 waren die Makefiles für die MFC im Lieferumfang enthalten und man konnte sich die MFC so selbst kompilieren. Das war insbesondere bei Visual C++ 6 eine große Hilfe, weil die damalige MFC gerade mal Windows 98 unterstützte und mit den neuen Datei öffnen/speichern-Dialogen von Windows 2000 und Dateigrößen von mehr als 4 GiB ein wenig überfordert war. Als Visual Studio 2005 aktuell war und ich Visual C++ 6 immer noch bevorzugte, habe ich die MFC8 so angepasst, dass sie auch mit Visual C++ 6 verwendet werden konnten. Nicht zu vergessen auch die WinSxS-Hölle, der man durch eine Neukompilierung entrinnen konnte und die Möglichkeit, die für mich überflüssigen Erweiterungen der BCGControlbar loszuwerden.

Abgesehen davon habe ich die MFC intern auch etwas erweitert, um dem Anwender eine gezielte Sprachauswahl zu ermöglichen. Dazu kommt noch der eine oder andere Fix, z.B. um die Datei öffnen/speichern-Dialoge generell größenveränderbar zu machen. Dies alles ist Geschichte, wenn es nach Microsoft geht. Die MFC ist bei Visual Studio 2010 zwar weiter im Quellcode dabei, aber es fehlen die wichtigen Makefiles für die Erstellung und die .DEF-Dateien für die Exporte. Möglicherweise werden die MSBuild-Optionen später im Visual C++ Team-Blog veröffentlicht. Das gleiche gilt auch für die C/C++-Laufzeit, wobei hier neben den Makefiles noch viele Dateien fehlen, die früher nur als .obj-Dateien ausgeliefert wurden.

Fazit

Es fällt nicht leicht, ein Fazit zu ziehen. Die blasse Schrift und das in Zukunft fehlende EasyTabs machen es mir ziemlich schwer, mich in Visual Studio 2010 wohlzufühlen. Die neuen Möglichkeiten der C/C++-Laufzeit und der MFC locken natürlich, obwohl die fehlenden Makefiles der MFC schon ein ziemlicher Showstopper sind. Aber mal schauen, vielleicht kann man ja die Makefiles von Visual Studio 2008 recyclen.

Top