2010-05-07 4 views
6

Ich habe eine Anwendung, die aus der Registrierung lesen soll und bei der Ausführung einer Konsolenanwendung funktioniert mein Registrierungszugriff perfekt.Führt Visual Studio Tests mit einem weniger privilegierten Prozess aus?

Jedoch, wenn ich es über zu einem Test bewegen gibt diese null:

var masterKey = Registry.LocalMachine.OpenSubKey("path_to_my_key");

Also meine Frage ist:

Ist Visual Studio laufen Tests mit einem weniger privilegierten Prozess?

Ich habe getestet, um zu sehen, welcher Benutzer das gab mir: var x = WindowsIdentity.GetCurrent().Name; und es gibt mir das gleiche wie in der Konsolenanwendung. Also bin ich hier etwas verwirrt.

Ich benutze MS Test Framework und die Maschine ist Windows 2003 64 Bit.

Antwort

1

Es ist kein Sicherheitsproblem. Es ist die Tatsache, dass Sie auf einem 64-Bit-Betriebssystem laufen. 64-Bit-Anwendungen haben eine andere Ansicht von HKLM \ Software als 32-Bit-Anwendungen. 64-Bit-Apps erhalten die "normale" Ansicht, 32-Bit-Apps werden zu HKLM \ Software \ Wow6432Node umgeleitet. Die EXE bestimmt die Bit-Ness des Prozesses, es wird anders sein, wenn Mstest den Code ausführt. 32-Bit, wahrscheinlich.

Sie müssen den Schlüssel erstellen, den Sie versuchen, in der Wow6432Node-Struktur zu lesen. Oder lassen Sie die normale App die gleiche Bit-Eigenschaft aufweisen, Projekt + Eigenschaften, Registerkarte Erstellen, Plattformziel = x86. Auch im laufenden Betrieb mit Corflags.exe änderbar.

+0

Wie kommt es funktioniert, wenn ich eine Konsolenanwendung für „Any CPU“ dann bauen? –

+1

@Filip, Jede CPU * ist * das Problem, das den Code im 64-Bit-Modus ausführt. Ihr Test wird im 32-Bit-Modus ausgeführt. Es gibt wahrscheinlich eine Version des MSTest-Hosts, die den Code im 64-Bit-Modus ausführen kann, ich weiß nicht genug darüber. –

+1

Überprüfen Sie diesen Blogpost: http://blogs.msdn.com/danielvl/archive/2009/03/28/run-mstest-exe-as-native-64-bit-process.aspx –

-1

würde ich ja sagen. Warum erwartest du etwas anderes? Es müsste auf diese Weise Windows Logo-kompatibel sein. Es ist auch aus Sicherheitsgründen gut. Visual Studio .NET ist Windows-Logo-konform, so würde man erwarten, dass es unter einem eingeschränkten Benutzer läuft

http://blogs.msdn.com/vcblog/archive/2006/09/06/742187.aspx

Verwandte Themen