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?
Perhaps too late but: Writing a custom tool in VS.NET
You might have skipped one of these steps:
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.
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
After executing this, my custom-tool worked perfectly.
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:
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.