Verschiedene VS.NET-Konfigurationen nutzen

Veröffentlicht: 22. Jul 2005

Von Mathias Schiffer

Mathias Schiffer zeigt Ihnen, wie Sie bei identischer Benutzeranmeldung verschiedene Konfigurationen von Visual Studio .NET parallel einsetzen können.

Auf dieser Seite

 Registry-Eintragungen von Visual Studio .NET
 Individuelles Visual Studio .NET per Kommandozeilenparameter
 Restriktionen
 Aufrufparameter
 Kleine Irritationen

Registry-Eintragungen von Visual Studio .NET

Visual Studio .NET speichert die meisten Optionen, die die Entwicklungsumgebung betreffen, nicht etwa in XML-Dateien, sondern in der Windows Registrierungsdatenbank (Registry). Dabei wird auch bei VS.NET unterschieden zwischen systemweit gültigen und für den jeweiligen Benutzer gültigen Einstellungen. Intuitiv ist, dass die Benutzereinstellungen denjenigen entsprechen, die der jeweils angemeldete Windows-Anwender eingestellt hat, während die systemweiten Einstellungen von allen Windows-Anwendern geteilt werden.

Hier finden Sie die entsprechenden Zweige in der Registry (per regedt32.exe oder regedit.exe):

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1

Möchten Sie verschiedene Konfigurationen von Visual Studio .NET nutzen, so können Sie mit verschiedenen Windows-Accounts arbeiten, unter denen Sie sich jeweils anmelden können, um eine auf bestimmte Weise konfigurierte Version von Visual Studio .NET nutzen zu können. Dank Windows-seitiger Innovationen wie der "schnellen Benutzeranmeldung" etc. mag man damit sogar leben können.

Wie wäre es aber, wenn Sie beliebig viele, völlig unterschiedliche Konfigurationen von Visual Studio .NET einfach per Verknüpfung starten könnten? Geht wegen der Natur der engen Anbindung von HKEY_CURRENT_USER an den angemeldeten Windows-Benutzer nicht, meinen Sie? Im Prinzip richtig - aber Visual Studio .NET hält eine versteckte Überraschung bereit!

 

Individuelles Visual Studio .NET per Kommandozeilenparameter

Wenn Sie bei der dargestellten Problematik daran gedacht haben, die relevanten Registryzweige zwecks Individualisierung jeweils beim Beenden der Entwicklungsumgebung zu exportieren und beim Starten jeweils wieder in die Registry zu importieren, liegen Sie schon gar nicht schlecht. Eine Verknüpfung auf ein simples Hilfsprogramm mit entsprechenden Anweisungen würde schon reichen (es müsste nicht einmal ein Add-In sein). Ein Nachteil dieser Idee jedoch wäre nicht wegzudiskutieren: Dieses Konzept funktioniert nur, wenn nicht mehrere Entwicklungsumgebungen parallel verwendet werden - es würde dann immer zu einem Kollisionskampf kommen (den im Zweifelsfall die zuletzt geschlossene IDE gewinnen würde).

Dankenswerterweise haben die Schöpfer der Entwicklungsumgebung uns jedoch ein noch viel flexibleres Werkzeug an die Hand gegeben:

Tatsächlich können wir nämlich beim Aufruf der Entwicklungsumgebung selber bestimmen, aus welchem Zweig in der Windows Registry Visual Studio .NET beim Starten seine Konfigurationseinstellungen auslesen soll. Das heißt nichts anderes, als dass wir für verschiedene Konfigurationen von Visual Studio .NET verschiedene Registry-Zweige anlegen können!

Dafür können Sie ganz hervorragend die Export- und Import-Funktionen des Registrierungsdatenbankeditors regedit.exe verwenden (Vorgehensweise: Export des Originalzweigs, Umbenennung des Originalzweigs in der Registry, Import des Originalzweigs unter seinem ursprünglichen Namen).

 

Restriktionen

Gänzlich frei sind die Auswahlmöglichkeiten für die zu verwendenden Registryzweige jedoch nicht. Tatsächlich muss der von Ihnen neu angelegte Registrypfad die bereits bestehenden, oben erwähnten Pfade erweitern. Sie können sich also nicht einfach irgendeinen Pfad in der Registry aussuchen. Gültige Beispiele wären etwa

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\7.1Strict

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\7.1Strict

Ungültige Beispiel sind z.B.

HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\Strict

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\Strict

Zudem müssen Sie bedauerlicherweise zwingend mindestens den alternativen Zweig aus HKEY_LOCAL_MACHINE selber anlegen, wofür Sie entsprechende Administratorrechte benötigen. Eigentlich ist dies kaum einzusehen - hier wäre eine flexiblere Handhabung der Entwicklungsumgebung wünschenswert.

Den Zweig für die Benutzereinstellungen können Sie zusätzlich kopieren, falls Sie die bisherigen Benutzereinstellungen als Grundlage für die neue Konfiguration verwenden möchten. Sie können darauf aber auch verzichten, da Visual Studio .NET dann einen auf Standardwerten beruhenden Registryzweig für den angemeldeten Benutzer neu anlegt.

 

Aufrufparameter

Die neu angelegten Registryzweige als separate Konfigurationen für Visual Studio .NET können Sie über den Kommandozeilenparameter "/rootsuffix" abrufen: Dabei verwenden Sie als Argument für den Parameter alleine die angelegte Erweiterung, also z.B. "Strict" - nicht etwa den kompletten alternativen Schlüsselnamen "7.1Strict".

Für das vorangestellte Beispiel könnten Sie Visual Studio etwa alternativ über die folgende Kommandozeile aufrufen:

DevEnv.exe /rootsuffix Strict

Natürlich können Sie diese Kommandozeile in Verknüpfungen verwenden, so dass Sie verschiedene Konfigurationen von Visual Studio .NET direkt starten können.

 

Kleine Irritationen

Eigentlich wollten die Schöpfer von Visual Studio .NET uns diese komfortable Möglichkeit verschiedener Benutzerprofile für identische Windows-Benutzer offenbar gar nicht einräumen - möglich wäre auch, dass sie dieses interessante Potential schlicht nicht erkannt haben. Deswegen wäre es auch tatsächlich unangebracht, Kritik dort anzubringen, wo wir als Anwender der Entwicklungsumgebung eigentlich gar nichts zu suchen haben.

Da wir nun aber schon einmal so weit vorgedrungen sind:

Lassen Sie sich bitte nicht dadurch irritieren, dass Visual Studio 2003 plötzlich die versuchte Übernahme von Einstellungen aus Visual Studio 2002 meldet, selbst wenn Sie diese Version niemals benutzt haben sollten:

Abbildung 1: Stimmt zwar nicht ganz - aber wir stimmen mit Ja.

Abbildung 2: Na also, geht doch - keine Neuwahl erforderlich!

Mathias Schiffer widmet sich als freier Softwareentwickler und Technologievermittler größeren Projekten ebenso wie arbeitserleichternden Alltagslösungen. Seit Jahren gibt er sein Wissen in unzähligen Publikationen und Beratungen auch an andere Entwickler und Entscheider weiter. Sie erreichen ihn per E-Mail an die Adresse Schiffer@mvps.org.