Integration Options does not see Visual Studio

Hi.

We use a couple of registry entries to determine the versions of Visual Studio that are installed, and also to find the location of the Addins directory into which we need to insert an xml file.

Can you take a look at HKEY_LOCAL_MACHINESOFTWAREWow6432NodeMicrosoftVisualStudio9.0ApplicationID
HKEY_CURRENT_USERSOFTWAREMicrosoftVisualStudio9.0VisualStudioLocation to see what they contain?

Can you do the same for the other versions of Visual Studio by replacing 9.0 with 8.0 and 10.0 too?

Thanks

You might also find my answer to this question, describing how to run a Visual Studio add-in (in VS 2010 admittedly) from a network share, helpful:

http://forums.reflector.net/questions/390/visual-studio-integration-does-not-work-from-file-share?page=1#395

I believe VS 2008 was more "relaxed" about forbidding the running of add-ins from network locations.

@Clive,

It appears to be that your product assumes that the user installed VS 2008 for "Current User" rather than for "All Users". You should have checked both HKCU and HKLM hives looking for this ApplicationID path. You aren't going to find it in the WOW registry if the OS is 32 bits. Surely you can tell if the machine is running 32 bits without having to poll for the existence of WOW keys. I notice there you do look at both HKCU and HKLM for that key but only HKCU for the other value of VisualStudioLocation. On my WinXP 32 install the applicationID you seek is under the Software-Microsoft-VisualStudio-9.0-ApplicationID but you only look for the WOW which 32 bit versions do not have. If you look at this and it appears to be the problem, please get it fixed so people don't have to keep wasting time and suffering frustration. I have had to dig to find this problem several times. We did our part and paid you. Please do yours!

Never mind on this one. It sort of "fixed" itself. There was no integrated menu but now there is. It never said anything about installing it and just left it unchecked saying it was not installed. Perhaps it should indicate it installed it and say that it is already installed rather that grayed out and still claiming VS 2008 is not installed when not only it is installed but also already integrated.

Hi there,

I've just submitted a patch that I hope will fix all of these problems, which we'll make available in a 7.4 early access build next week, however I think I should probably clear a few things up.

The first is that we're not using the registry to "guess" the OS architecture. We have code to check that more reliably elsewhere, however the answer is always from the point of view of the process doing the checking. In other words, even on a 64-bit OS, if you're running as a 32-bit process, the OS architecture will appear to be 32-bit. To get Reflector to run this way you'd have to force it, which there's no really good reason to do that, but it's certainly possible. Even if this was done, it's not clear why in and of itself it would cause problems for the Visual Studio install detection - my belief is that it shouldn't (not that there weren't other problems, see below).

Back on point, I noticed some slightly sloppy logic that meant we were checking the Wow6432Node even when running as 32-bit because it wasn't actually looking at the processor architecture at all. I've now removed this check on 32-bit systems. On 64-bit we check the Wow6432Node but if we don't find the VisualStudioLocation value there, we just use HKCU\Software or HKLM\Software - the latter is something I've added this afternoon to fix one of the problems you highlighted. Visual Studio is a 32-bit app but it doesn't store everything under the Wow6432Nodes in the registry - I'm not sure why this is, but it may be to make it easier for other applications to query that information - so we need to play it safe and check both locations.

Finally, I'm not sure why you would think we are creating keys under Wow6432Node. We use RegistryKey.OpenSubKey, which definitely does not create the queried key where it doesn't already exist - in fact it returns null in this circumstance. If you use Reflector to drill through the OpenSubKey overloads you can see that it calls the Win32 API RegOpenKeyEx method, which also doesn't create keys. You can find more information about this at http://msdn.microsoft.com/en-us/library/z9f66s0a.aspx, and http://msdn.microsoft.com/en-us/library/ms724897(v=vs.85).aspx. My guess is some other application or add-in is creating these keys, which then confuses Reflector causing it to report that Visual Studio isn't installed. This should also now be fixed.

I hope that clears matters up a bit. I'll post here when the new 7.4 early access build is available.

Thanks,

Bart

This should now be fixed in 7.4 EA build 2, which you can download from the bottom of the homepage at www.reflector.net. I have a blog ready to go with more detailed information about the other changes we've made in this build, but due to a problem with Wordpress I probably won't be able to publish that until tomorrow.

Please let me know if you have any further problems with this.

Thanks,

Bart

i have a simple install of visual web developer express and I have checked all the registry settings mentioned above. But still do not have ability to integrate the .net reflector. Same problem as at beginning of this thread.

BTW: You might find that the SOFTWARE-WOW6432 exists after looking in to integrating Reflector via the Reflector dialog. This is because when you "query" to see it there is a WOW6432 you use RegOpenKey rather than RegQueryKey. RegOpenKey does just that. It creates the Key if it does not exist which it won't on a 32 bit machine. So you are creating a fake 64 bit hive in Windows 32 because you open instead of query.

If the user adds the ApplicationID=VisualStudio registry value to the key you create, it fixes this issue which proves what the problem is and how simple it is to fix. Please fix it.

Also, your code doesn't know if the OS is 32 bit versus 64 bit you can test this simply without the API.

sizeof(int *) == 4 - OS is running 32 bit (DON"T QUERY FOR A REGISTRY WOW)

sizeof(int *) == 8 - OS is running 64 bit (QUERY THE REGISTRY WOW)

And again, check BOTH HKLM and HKCU regardless of 32/64 bits! You do not know which one the user chose (or had chosen for him) when he installed VS 20xx.