kürzlich bekam ich vom Visual Studio 2010 Debugger beim Starten einer Anwendung folgende Fehlermeldung:

—————————
Microsoft Visual Studio
—————————
Fehler beim Ausführen des Projekts: Das Programm “…\unittest\bin\Debug\unittest.exe” kann nicht gestartet werden.

Das Debuggen im gemischten Modus für x64-Prozesse wird nur bei Verwendung von Microsoft .NET Framework vor Version 4 unterstützt.
—————————
OK   Hilfe
————————–

Die Konstellation war dabei folgende:

• Ein reines C#-Programm referenziert eine Assembly, die mit managed C++ erstellt war. Diese Assembly bindet auch native code ein (mixed mode).
• Als Compiler wurde der vc90 verwendet.
• Als Targetversion für das .NET-Framework wurde für alle Komponenten 2.0 verwendet.
• Alle Anwendungen waren als 32-Bit-Anwendungen in Visual Studio 2008 erstellt und wurden von Visual Studio 2010 zur Version 2010 konvertiert.

Für die in C# erstellte (reine .NET) Anwendung war in den Einstellungen als Zielplattform “Any CPU” eingetragen, wie bereits in der Vorgängerversion:

Nach der Umstellung auf X86 konnte die Anwendung erfolgreich im Debugger gestartet werden.

Die Fehlermeldung ist grundsätzlich ziemlich irreführend. Alle beteiligten Komponenten waren ja explizit für .NET 2.0 konfiguriert.

Oder ist sie gar falsch?

Auf dieser Seite findet man folgendes Zitat:

Debugging im gemischten Modus (Aufrufe von systemeigenem Code bis zu verwalteten Codes, oder umgekehrt) wird für x64-Prozesse unterstützt, wenn der verwaltete Code Microsoft .NET Framework, Version 4 oder höher, verwendet.

Debugging im gemischten Modus wird nicht für IA64-Prozesse oder x64-Prozesse unterstützt, die frühere .NET Framework-Versionen als 4 verwenden.

was ja ein klarer Gegensatz zur oben zitieren Fehlermeldung ist.

Grundsätzlich ist es schon etwas unschön, wenn man für die reine .NET-Komponent nicht mehr “Any CPU” wählen kann, nur weil sie eine mixed mode Assembly nutzt, die im 32-Bit Modus erstellt wurde.

Eine Rolle könnte auch spielen, dass ich inzwischen Windows 7 x64 benutze, während ich zuvor Windows XP X86 verwendet habe.

Viele Grüße,
Andreas

Technorati Tags: Visual Studio, mixed mode, debugging

es gibt eine klare Empfehlung für die tägliche Arbeit auf einem Computer mit Windows XP ein Konto mit eingeschränkten Rechten zu verwenden. Der Hauptgrund ist die damit stark reduzierte Wahrscheinlichkeit einem Virus oder anderer Malware zum Opfer zu fallen.

Für Entwickler gibt es noch einen weiteren, wesentlichen Grund für die Verwendung eines Kontos mit eingeschränkten Rechten: sie testen damit automatisch, ob die entwickelte Software auch mit eingeschränkten Rechten funktioniert – was gut geschriebene Software machen sollte.

Dummerweise bekommt man bei diesem vorbildlichen Vorgehen ein Problem, wenn man eine ATL COM Komponente erzeugt. Für diesen Projekttyp aktiviert Visual Studio die Linker Option “Ausgabe registrieren”.
Damit wird nach erfolgreichem Linken der Komponente regsvr32 /s aufgerufen, um die frisch erstellte Library zu registrieren. Dieser Aufruf scheitert bei Verwendung eines Kontos mit eingeschränkten Rechten da die Registrierung von COM-Komponenten Administrator-Rechte erfordert:


Project : error PRJ0050: Fehler beim Registrieren der Ausgabe. Vergewissern Sie sich, dass Sie über die entsprechenden Berechtigungen zum Ändern der Registrierung verfügen.


Für solche Fälle ist die Verwendung des Kommandos runas eine naheliegende Option aber leider hat man auf die von Visual Studio erzeugte Programmzeile für den Aufruf von regsvr32 keinen Einfluss, diese ist nämlich Teil der Visual Studio Programmierschnittstelle und damit nicht direkt zugänglich.

Eine einfache Lösung besteht darin, die oben genannte Linker-Option “Ausgabe registrieren” zu deaktivieren und ein eigenes “Postbuildereigenis” für das Projekt zu definieren. Dieses könnte z.B. so aussehen:


runas /user:administrator /savecred "regsvr32 /s $(TargetPath)"


Damit das funktioniert muss man einmal den Befehl in einem Kommandofenster eingeben und dann nach der Aufforderung das Administrator-Password eingeben. Bei jedem weiteren Aufruf mit /savecred wird dann das zuletzt verwendete Passwort automatisch verwendet. Damit ist vermieden, dass das Administrator-Password im Klartext in einer Visual Studio Projektdatei steht, was eine erhebliche Sicherheitslücke darstellen würde.

Falls man das gemerkte Passwort später wieder löschen möchte: Systemsteuerung/Benutzerkonten/Eigene Netzwerkkennwörter verwalten.

Viele Grüße,
Andreas

Technorati Tags: Visual Studio, COM, ATL, Registry, Eingeschränkter Benutzer

Meine Name ist Andreas Awenius. Ich bin selbständiger Berater für Softwareentwicklung in den Bereichen, Microsoft Windows, .NET, C++, UML und Unix. Auf meiner Homepage können Sie sich weiter über mich informieren.

Auf diesem blog werde ich in loser Folge über verschiedene technische Aspekte und sonstige interessante Entwicklungen im Bereich der Softwareentwicklung schreiben. Über Kommentare und Fragen freue ich mich immer.

Viele Grüße,
Andreas