Visual Studio 2010 Tipps & Tricks #7 – Der Administrator und die Extensions
Das Problem
Wenn man Windows Azure Projekte entwickelt, muss man sein Visual Studio als Administrator starten, da fehlt dann schon mal die ein oder andere Projektvorlage oder Extension. Seit Windows Vista wissen wir Entwickler über die Virtualisierung und UAC Bescheid, aber wissen wir auch über die Visual Studio Extensions Bescheid? Viele Vorlagen und Templates die wir in unserem Alltag als Entwickler verwenden haben wir selber erstellt oder verwenden Vorlagen von Codeplex und Co. Eines der besagten Templates ist zum Beispiel: Das Windows Azure Toolkit for Windows Phone 7. Erst einmal installiert kann man direkt loslegen …
Ist das Projekt angelegt und man versucht es zu starten so erhält man eine Fehlermeldung:
Natürlich, man hat mal wieder vergessen Visual Studio als Administrator zu starten. 
Also startet man sein Visual Studio als Administrator. Aber jetzt fehlen die “Project Templates” des Windows Azure für Windows Phone 7 Toolkits.
Auch die geliebten kleinen Helfer werden nicht geladen. Schauen wir uns erst an, wie wir dem Abhilfe schaffen können, bevor wir nach den Gründen suchen.
Die Lösung
Unter Tools –> Options findet man unter Environment die Einstellungen des Extension Managers.
Aktiviert man die Option: “… Load per user extensions when running as administrator …”
Ist das Problem behoben und man muss auch als Administrator nicht mehr länger auf seine Extensions und Projektvorlagen verzichten.
Allerdings bleibt da noch die Frage:
Warum werden meine Visual Studio Extensions nicht im Administrations / Administrator Modus geladen?
Die Gründe
Die Antwort auf diese Frage ist wieder einmal länger als die Lösung des Problems. Hinter den Extensions stecken die sogenannten VSIX Module.
Was ist ein VSIX Modul?
(“VSIX - Steht für Visual Studio Extension und sollte eigentlich VSX heißen. VSX war aber schon von Visio belegt, deshalb VSIX.”) 
Das primäre Ziel dieser Module? Es soll die Erweiterbarkeit von Visual Studio und das Austauschen, Updaten, Suchen sowie Ein- und Ausschalten von Erweiterungen vereinfachen. Visual Studio erkennt Dateien mit der Dateiendung VSIX und kopiert den Content innerhalb des Deployment Containers (VSIX) an die richtige Stelle.
VSIX Dateien sind ZIP Dateien welche die Open Packaging Convention (OPC) verwenden. Wie Office Dokumente (ab 2007) kann man auch VSIX Dateien durch umbenennen in *.zip und öffnen mit einem Paketierungsprogram oder dem Windows Explorer (ab Windows Vista) durchsuchen.
Hier ist der Aufbau einer VSIX Datei vereinfacht dargestellt.
1. Content Types
[Content_Types].xml beschreibt den Inhalt des Paketes. Diese Liste von Dateitypen wird von der „Open Packaging Convention API“ benötigt.
2. Extension Manifest
Das Extension Manifest beschreibt das VSIX Paket. Diese Informationen werden auch vom Extension Manager angezeigt. Mehr Infos und Best Practices hat mein Kollege Gary Horen zusammengefasst.
3. / 4. Product Payload und Supporting Files
Das „Product Payload“ repräsentiert die „Project Binaries“ und Dateien. „Supporting Files“ können Icons, Images, Readme Files, License terms und alle anderen Dateien sein. Mehr Informationen zur Anatomie von VSIX Modulen findet man auf MSDN und auf den Blog von Quan.
Während der Installation wird der Inhalt der VSIX Datei per Default in folgenden Ordner kopiert:
%LocalAppData%\Microsoft\VisualStudio\10.0\Extensions\
Extensions die über den Extension Manager oder über das VSIX File installiert wurden werden automatisch geladen. Extensions die selbst in diesen Ordner kopiert wurden sind Standardmäßig erst mal deaktiviert. Können aber über den Extension Manager nachträglich aktiviert werden.
Startet man Visual Studio schaut es an den bekannten Ordnern nach, welche Erweiterungen in welcher Version geladen werden müssen.
Was es mit den Versionen auf sich hat, hat mein Kollege Kary Horen (Blog Post oben) ja schon erklärt. An der Stelle sei noch erwähnt, dass MEF Assemblies verwendet werden können. Einen der Ordner kennen wir schon. %LocalAppData%\Microsoft\VisualStudio\10.0\Extensions. Weitere Ordner in denen sich Extensions befinden können werden in der “Master PkgDef” Datei definiert. Diese Datei findet man unter:
<WoAuchImmerVisualStudioInstalliertWurde>\Common7\IDE\devenv.pkgdef
Darstellung der Master PkgDef
Variable: ApplicationExtensionFolder
Beschreibung: Der “Root Folder” unter dem Systemweite VSIX Dateien deployed werden.
<WoAuchImmerVisualStudioInstalliertWurde>\Common7\IDE\ExtensionsVariable: UserExtensionsRootFolder
Beschreibung: Der “Root Folder” unter dem User spezifische VSIX Dateien deployed werden.
%LocalAppData%\Microsoft\VisualStudio\10.0\ExtensionsVariable: PkgDefSearchPath
Eine Liste von weiteren Ordnern in denen nach Extensions gesucht werden soll. Hier findet man auch einen Verweis auf den ApplicationExtensionsFolder.
Während der Initialisierung von Visual Studio sucht der Extension Manager Service (SVsExtensionManager) innerhalb der oben beschriebenen Ordner nach extension.vsixmanifest Dateien. Zuerst wird im PkgDefSearchPath Ordner gesucht gefolgt vom UserExtensionsRootFolder.
Ladeverhalten von Extensions
Bevor eine Extension vom Extension Manager geladen wird muss sie vorher ein paar Tests über sich ergehen lassen:
Ist das XML Manifest der Extension XSD konform?
Wenn das XML Manifest nicht XSD konform ist, wird die Extension ignoriert. Andernfalls wird das Manifest in ein Object deserialisiert und in den Speicher geladen.
Ist die Extension nicht zum Löschen markiert?
Wenn man eine Extension über den Extension Manager deinstalliert passiert das sehr schnell. Das liegt daran, dass eine Extension nur zum Löschen markiert und nicht wie erwartet sofort gelöscht wird. Der Grund dafür ist, dass die Extension evtl. noch in Visual Studio geladen ist und das Löschen bzw. deinstallieren kann im Falle von einigen Extension zu Abstürzen und zu ungewollten „Side effects” führen. Der eigentliche Löschvorgang wird bei der nächsten Initialisierung von Visual Studio durch einen Background Worker Thread durchgeführt. Deshalb wird beim Starten von Visual Studio überprüft ob die Extension geladen werden oder gelöscht werden soll.
NOTE: Kann eine Extension aus diversen Gründen nicht geupdated werden, kann man eine Extension deinstallieren. Visual Studio schließen. Neu starten und noch einmal schließen. Erst jetzt wird die Extension deinstalliert. Jetzt kann man das Update der Extension nach einem erneuten Start über den Extension Manager installieren. ( z.B. NuGet update auf Version 1.2 )
Ist der Identifier der Extension unique oder besteht ein Konflikt mit einer zuvor geladenen Extension?
Wird eine Extension mit derselben ID wie eine bereits geladene Extension ID entdeckt, wird sie nicht berücksichtigt.
Das ist der Augenblick in dem die Suche interessant wird. Der „UserExtensionsRootFolder“ wird zuletzt durchsucht. Ist also eine Extension Systemweit über mehrere Benutzer hinweg installiert, wird Sie nicht mehr aus dem User Verzeichnis („UserExtensionsRootFolder“) geladen sondern aus dem Systemweiten „ApplicationExtensionFolder“.
Hat eine Extension diese Checkliste überstanden, gilt Sie für den Extension Manager Service als installiert. Um herauszufinden welche Extension installiert, deinstalliert oder beschädigt ist ( Checks nicht überstanden ) kann man Visual Studio im „Activity Log Modus“ starten. Beim Laden schreibt der Extension Manager dann Einträge für jede Extension in das Visual Studio “Activity Log”. Das “Activity Log” kann durch folgenden Parameter beim Start von Visual Studio aktiviert werden.
devenv.exe /log <WoAuchImmerManDasLogSpeichernWillAlsPfadZurDatei>
Mehr zum Ladeverhalten von VSIX Dateien findet man auf dem Blog von Dmitry. Was es mit den PkgDef auf sich hat kann man auf dem Visual Studio Team Blog nachlesen. Und Aaron erklärt auf seinem Blog das PkgDef Konzept in Visual Studio 2010.
Enabled / Disabled Extensions
Zuvor haben wir uns mit dem installieren / deinstallieren und der Location, Location, Location Problematik beschäftigt. Was noch fehlt in unserer Betrachtung von Visual Studio Extensions ist:
“Wie behandelt der Extension Manager Extensions, die Enabled bzw. Disabled sind.”
Und damit kommen wir auch final zum oben beschriebenen Problem. Die Antwort lautet: “It depends!”
Alle Extensions die in der PkgDefSearchPath Liste stehen werden immer geladen. Also auch die Systemweit installierten Extensions. Extensions die im „UserExtensionsRootFolder“ liegen müssen über eine Liste individuell gehandhabt werden. Diese Liste findet man in der Windows Registry unter:
HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\10.0\ExtensionManager\EnabledExtensions
Die Extension Manager Install API, die auch vom „Extension Install Dialog“ verwendet wird fügt dieser Liste einen Eintrag mit der korrespondierenden Extension hinzu. Das ist auch der Grund, weshalb Extensions die von Hand in eines der Verzeichnisse kopiert werden dediziert als Enabled definiert werden müssen. Einfach deshalb, weil der Entsprechende Eintrag in der Registry noch nicht gesetzt wurde.
Und nun die Brücke zu Windows. Da bei Windows bekanntlich eine Vitalisierung der Registry stattfindet, fehlen diese Einträge, sobald man Visual Studio als Administrator startet. Visual Studio bietet dem Entwickler allerdings an, dieses Problem für Ihn zu beheben. Siehe Lösung. Sollte dieses Feature nicht aktiviert sein, erscheint ein Hinweis im Extension Manager.
Zusammenfassung
Extensions sollen einem den Alltag leichter machen. Und das VSIX Konzept ermöglicht es der Community und den 3thrd Party Herstellern über die „Visual Studio Gallery“ ihre Lösungen zur Verfügung zu stellen. Als Entwickler einer Extension sollte man über die oben beschriebene Funktionsweise von Extensions Bescheid wissen. Und als Konsument sollte man wissen, warum die Extensions im „Elevated Modus / Admin Modus“ nicht laufen.