views:

67

answers:

2

I have an application that is supposed to read from the Registry and when executing a console application my registry access works perfectly.

However when I move it over to a test this returns null:

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

So my question is:

Does Visual Studio run Tests with a less privileged process?

I tested to see what user this gave me: var x = WindowsIdentity.GetCurrent().Name; and it gives me the same as in the console application. So I am a bit confused here.

I am using MS Test Framework and the machine is Windows 2003 64 Bit.

+1  A: 

It is not a security issue. It's the fact that you are running on a 64-bit operating system. 64-bit apps have a different view of HKLM\Software than 32-bit apps. 64-bit apps get the "normal" view, 32-bit apps are redirected to HKLM\Software\Wow6432Node. The EXE determines the bit-ness of the process, it will be different when mstest runs the code. 32-bit, probably.

You'll need to create the key you are trying to read in the Wow6432Node tree. Or make the regular app have the same bit-ness, Project + Properties, Build tab, Platform Target = x86. Also changeable on-the-fly with Corflags.exe.

Hans Passant
How come it works when I build a console application for "Any CPU" then?
Filip Ekberg
@Filip, Any CPU *is* the problem, that runs the code in 64-bit mode. Your test runs in 32-bit mode. There's probably a version of the mstest host that can run the code in 64-bit mode, don't know enough about it.
Hans Passant
Check this blog post: http://blogs.msdn.com/danielvl/archive/2009/03/28/run-mstest-exe-as-native-64-bit-process.aspx
Hans Passant
But I've already set my Test Project to run as x86, but it's still the same outcome. Can I somehoe sync the registry trees?
Filip Ekberg
I think you're still missing the point. Run Regedit.exe and add the key your test program needs. In HKLM\Software\Wow6432Node
Hans Passant
Also, I don't really see this as a solution to have to manually add the registry key. If I type regedit and my key is there, I want to be able to access it with the Unit tests just like I can in an ordernary applicaiton. Otherwise TDD will be just too much work.
Filip Ekberg
Your App is running on 64 bits and your Test in 32 bits you have to make sure both run on the same version.
Gabriel Guimarães
@Filip, how did the registry key get there in the first place? It was done wrong, it was written by a 64-bit process. Incompatible with your test setup. Change the setup. Or change the process. Or write the key in both places. Plenty to choose from.
Hans Passant
The Registry key was written there by Microsoft Dynamics AX2009 and installed on a 64Bit Machine. WITH a `64 bit` console application I can open and read the Key. WITH a `64 bit` AND a `32 bit` test, I cannot. Does this only apply to ms-test? would nUnit run as 64Bit? I gathered that I cannot access the registry with a 32 Bit app when the OS is 64Bit ( at least not if the key isn't shared in both Nodes ). And _why_ are the tests running as 32 bit when the os is 64 bit? It makes no sense..
Filip Ekberg
@Filip: I linked to the blog post. Mstest.exe is marked to always run in 32-bit mode. The blog post shows you how to tinker it so the test will run in 64-bit mode. Again, the lowest pain point is to simply make the registry key available in Wow6432Node. If anything, it removes the dependency your test has on MD having done its job properly. You mock MD.
Hans Passant
So, to make the Tests portable to all developers, using all different bits on their OS:es. The safest way would be to just, don't talk to the registry in the tests? I mean, it is easy to have a test failing because you simply didn't copy it to the Right node.. Or maybe there's some kind of "sync" software one could use? Thanks Hans, you provided me with a solution, even though I didn't really like it :)
Filip Ekberg
A: 

I would say yes. Why do you expect anything different? It would have to be this way to be Windows Logo compliant. It's also good from a security viewpoint. Visual Studio .NET is Windows Logo compliant, so you would expect that it runs as a restricted user

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

daveangel