Back to Questions
1.4k
views9
comments
Issues finding HKLM registry key from F# fsi interpreter
f#functional

Hi

I am kind of new to F#, but I did some Scheme in college so I know a bit about what functional languages are about. I am working for one of the MS Office teams and I want to do some work with F# specifically because the interpreter would make some of my job a lot easier.

I have some F# code that calls some of my teams managed libraries, and I am finding that the compiled code works just fine but that the interpreted code chokes on a registry key open. The Method that is getting called is Microsoft.Win32.Registry.LocalMachine.OpenSubKey(string), and I pass it a path to @"SOFTWARE\Microsoft\Office\..." (can't really show the rest of the path). The key I want to get doesn't work in the interpreter, but the key one level above it does, and the sub keys of that are only 2 of the other 5 keys.

Are there known to be any issues with opening HKLM registry keys from fsi? This stuff all works when compiled (that OpenSubKey doesn't return a null, and as a result doesn't cause some other exception to get thrown).

-Thanks

PL

.

Code:

let key = Microsoft.Win32.Registry.LocalMachine.OpenSubKey(@"Software\Microsoft\Office");;

let sub = key.GetSubKeyNames();;

print_any sub;;

Output from Compiled Version:

[|"12.0"; "Outlook"|]

Output from Interpreted version:

[|"11.0"; "12.0"; "8.0"; "Common"; "Delivery"; "Excel"; "InfoPath"; "Outlook";

"Word"|]

The compiled version is what I actually see in regedit.

By on 9/3/2008 9:26 PM ()

FYI, this does not repro for me (both compiled and VFSI yield same result, and that result matches regedit).

By on 9/3/2008 10:23 PM ()

I tried this code in the interpreter on my email box at work (which is Vista Enterprise 32bit) and it works fine.

So maybe I don't get this but, do 32bit processes have a different view of the registry?

By on 9/4/2008 9:24 AM ()

Works correctly on Windows XP SP3

By on 9/4/2008 9:42 AM ()

So I fixed the problem:

[link:cs.hubfs.net]

Used corflags to change the 32bit flag on the fsi.exe assembly.

[link:msdn.microsoft.com]

So should absilsuppc.dll work ok for me even though I am running fsi in 64mode?

By on 9/4/2008 2:16 PM ()

absilsuppc.dll will not load into the 64-bit process. This should not be an issue for fsi.exe, since absilsupcc.dll only implements code signing, native resource linking and command-line compiler debug symbol generation.

By on 9/4/2008 3:15 PM ()

Is there any chance this will be released as an x64 binary? Are there any limitations or issues?

By on 9/5/2008 2:53 PM ()

I know now where these things are going:

HKLM\SOFTWARE\Wow6432Node

The WOW stuff is messing me up here.

Is there a 64bit version of fsi?

By on 9/4/2008 9:55 AM ()

I have tried this on my machines at work (ws2008 64bit), and at home (Vista Ultimate x64). What are you running?

By on 9/4/2008 9:14 AM ()

    Topic tags

    IntelliFactory Offices Copyright (c) 2011-2012 IntelliFactory. All rights reserved.
    Home | Products | Consulting | Trainings | Blogs | Jobs | Contact Us | Terms of Use | Privacy Policy | Cookie Policy     		Built with WebSharper