I have some code that I'm writing. I'm a newcomer with C#, so I wrote my sample and compiled it using the framework csc as a test. That worked OK, so I downloaded Visual Studio 2013 (Community Edition). The following is my code:
using System;
using Microsoft.Win32;
public class Example
{
public static void Main()
{
const string subkey = "Software\\Python\\PythonCore";
RegistryKey py = Registry.LocalMachine.OpenSubKey(subkey);
foreach (string ver in py.GetSubKeyNames()) {
RegistryKey pathkey = py.OpenSubKey(ver + "\\InstallPath");
string path = (string)pathkey.GetValue("");
Console.WriteLine("{0}: {1}", ver, path);
}
py = Registry.CurrentUser.OpenSubKey(subkey);
foreach (string ver in py.GetSubKeyNames()) {
RegistryKey pathkey = py.OpenSubKey(ver + "\\InstallPath");
string path = (string)pathkey.GetValue("");
Console.WriteLine("{0}: {1}", ver, path);
}
}
}
It has a problem in that I don't check if the OpenSubKey calls succeed, but that's not (directly) the issue.
Compiling this with "C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe .\csexample.cs" and running it, it works fine. Creating a Visual Studio Console application project and pasting the code in and running it from there, it fails with a null pointer exception on the first call to OpenSubKey (which is the one that does exist). Using the Visual Studio 2013 developer command prompt, "csc .\csexample.cs" works, just as the framework compiler did.
I have two problems here. First, why would the Visual Studio build work differently (obviously it's compile options somehow, but I can't get VS to show me the command line it ran, so I can't see what's different). And second, why would I be getting a null pointer from OpenSubKey in any case, when the key is there (as evidenced by the fact that the command line compiled version finds the data!)
Sorry if this is a dumb question. I thought I'd switch to VS as I want to add a GUI round the basic code, and I thought VS would make that easier. Having previously working code suddenly start failing is very frustrating.
Thanks, Paul
PS If the issue is a bug in my code that was undetected in the command line compiled version, that's fine. I can accept that. But I'd have hoped, if VS is detecting the bug, it would tell me what the heck is wrong, rather than just silently behaving differently!!! Again, am I doing something wrong such as not looking at the right bit of output?
No comments:
Post a Comment