Eigentlich muss einen das nicht weiter interessieren, denn Windows 8 nutzt normalerweise die x64-Version des Internet Explorer.

Ganz anders sieht das für Entwickler aus. Visual Studio will die x86-Version starten, weil nur dort ein Debugging möglich ist. Falls man also von diesem Bug betroffen ist erkennt man das womöglich daran, dass sich keine Web-Projekt im Visual Studio starten lassen. Stattdessen bekommt man lediglich folgenden Fehlerhinweis:

Es gibt verschiedene Wege aus diesem Problem, allerdings gibt es keinen Workaround der vollständig zufriedenstellend ist.

Alternative Browser

Hat man einen alternativen Browser installiert, so kann man diesen im Visual Studio in der Toolbar auswählen:

Und damit klappt der Start dann ohne Probleme… abgesehen davon, dass man dann kein JavaScript debuggen kann.

Zumindest funktioniert dieser Weg immer.

Attach to Process

Eine andere Lösung die sich im Web findet bzw. auf die man durch Ausprobieren kommt, ist folgende: In den Projektsettings “Don’t open a page” auswählen, und dann den manuell gestarteten Internet Explorer auf die Startseite lenken.

Dummerweise hat man hier zunächst auch kein Script-Debugging. Die Auswahl des Debuggers aus dem Internet Explorer heraus funktioniert nicht, die laufende Instanz des Visual Studio wird einem nicht angeboten, wohl weil sie schon einen Prozess debuggt. Man kann aber im Visual Studio über DEBUG/Attach to Process den Internet Explorer auswählen. Interessant dabei ist folgender Effekt:

Voraussetzung: Im Internet Explorer muss in den Settings Script Debugging aktiviert sein.

Ich habe nur eine Instanz gestartet und finde trotzdem drei Prozesse:

Die mit der korrekten Homepage angegeben Instanz ist als x64 ausgewiesen und unterstützt kein Script-Debugging. Nach dem Auswählen der mit “x86, Script” ausgewiesenen Instanz konnte ich aber trotzdem problemlos debuggen. Hier die richtige Instanz zu finden dürfte nicht immer ganz einfach sein.

Stecker ziehen

Da die eigentliche Ursache nicht im Visual Studio sondern im Internet Explorer liegt, kann man auch versuchen hier anzugreifen.

Durch die Anmeldung am Active Directory wird für den User ein Home-Verzeichnis vergeben. Solange dies auf ein Netz-Share verweist, scheint der Internet Explorer Probleme zu haben:

Der erste Aufruf erreicht genau nichts, und wie man sieht verweist das Home-Verzeichnis auf ein Netzshare.

Ein Weg, der bei uns recht zuverlässig funktionierte ist: Netzwerkstecker ziehen! (sic!)

Wenn man bei der Anmeldung an Windows keine Netzverbindung hat, laufen die entsprechenden Skripte nicht ab, es wird kein Home-Directory vergeben, etc.. Danach kann man den Netzwerkstecker wieder einstöpseln.

Diese “Lösung” funktionierte bei uns bei mehreren Kollegen, ist aber vermutlich nicht immer eine Option.

Umgebung anpassen

Man kann natürlich auch die Umgebungsvariablen umsetzen und es dann erneut versuchen:

Falls der Internet Explorer jetzt ohne Probleme startet, hat man einen einigermaßen brauchbaren Workaround. Startet man Visual Studio von der gleichen Kommandozeile hat man auch keine Probleme beim Start oder Debuggen der Web-Anwendung.

Dummerweise funktionierte das nicht bei allen Kollegen, so dass dieser Workaround leider nicht besonders zuverlässig ist.

Sollte er aber funktionieren, will man ihn natürlich auch nutzen: Das nächste Problem ist nun, dass diese Umgebungsvariablen am Domänen-Account gesetzt werden, und sich weder in den Systemeinstellungen noch über ein lokales Anmelde-Script ändern lassen.

Ergo muss eine entsprechende Batchdatei her, die das bei jedem Start von Visual Studio umsetzt:

set HOMEDRIVE=C:
set HOMEPATH=Usersusername
set HOMESHARE=c:Usersusername
c:
cd "C:Program Files (x86)Microsoft Visual Studio 11.0Common7IDE"
start devenv.exe %1 %2 %3 %4 %5 %6

Username durch den Anmeldenamen ersetzen, Visual Studio über diese Batchdatei starten, alles wird gut

Versucht man über den Explorer eine Solution-Datei direkt zu öffnen, so bekommt man u.U. folgende Auswahl (falls diese nicht kommt, einfach im Kontextmenü unter “Öffnen mit” ein neues Programm auswählen):

Hier kann man ebenfalls die Batchdatei als Programm auswählen, so dass auch dieses Szenario abgedeckt ist.

Warten auf Microsoft

Die letzte Option ist natürlich zu warten, bis Microsoft einen Fix bereitstellt. Bekannt ist das Problem dort bereits:

Thanks all for the confirmation. IE team get the repro and is fixing it. When they deliver the fix, I’ll let you all know. Currently, please use the workarounds shown in the Workarounds tab.

If you encountered the issue which not related to "Homedrive" environment variable, please let us know asap, as there might be other causes.

Sorry for the trouble. Thanks again!

Xinyang Qiu
Web Platform and Tools team