Visual Studio custom tool for code generation... how do I find out what's going wrong?

Question

I'm trying to create a custom tool for code generation in Visual Studio 2010. First I register it:

"$(FrameworkSDKDir)Bin\NETFX 4.0 Tools\gacutil.exe" /if "$(TargetPath)"

Then I add it via a reg key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\CLSID\{6A96476E-74F3-4AB3-9CCA-F15EC6104D84}]
"RuntimeVersion"="v4.0.30319"
"Class"="MapBuildTool.MapFileGenerator"
"Assembly"="MapBuildTool, Version=1.0.0.0, Culture=en-US, PublicKeyToken=7d8abca94a1e38ae"
"ThreadingModel"="Both"
"InprocServer32"="C:\\Windows\\SysWOW64\\mscoree.dll"
@="MapBuildTool"

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Generators\{FAE04EC1-301F-11D3-BF4B-00C04F79EFBC}\MapBuildTool]
"CLSID"="{6A96476E-74F3-4AB3-9CCA-F15EC6104D84}"
"GeneratesDesignTimeSource"=dword:00000001
@="MapBuildTool"

And then visual studio says:

Cannot find custom tool 'MapBuildTool' on this system.

OK... now what? Did it not find the custom tool registry key? Did it find the key but have trouble loading the assembly? Did it load the assembly but have trouble instantiating the class ...? What logs/places are there where I can look to find out what's wrong?

Answer 1

I ran into this issue with a custom-tool that I wrote yesterday. Extremely frustrating. The reg file was correct, the custom-tool ran perfectly in the Experimental Hive. But it simply refused to run in regular VisualStudio.

I'm guessing that VisualStudio reads the registry and then caches pieces of the registry somewhere.

Executing the following appear to reset this cache

devenv /setup

After executing this, my custom-tool worked perfectly.

Answer 2

Perhaps too late but: Writing a custom tool in VS.NET
You might have skipped one of these steps:

Register your Generator for COM interop

You have to generate a GUID and use tlbexp.exe and regasm.exe. I assume you have to use these tools instead of putting the generator in the GAC.

Answer 3

To debug:

Run Process Monitor to reverse engineer the VS2010/COM/.NET/Fusion assembly-loading nightmare, looking at what registry entries of yours VS picks and which ones it tries to find but fails with NOTFOUND on.

To hopefully fix without having to debug:

Option 1:

Add a binding path:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\BindingPaths\<A new GUID>]
"<Path the the folder containing your DLL>"=""

Option 2:

I'm not sure about this, but I think you could create a proper VS2010 package (instructions), which will take care of registering the executable file locations.

For both options, neither gacutil, tlbexp, nor regasm is required. VS2010 does its own thing when finding DLLs.