We’ve released a slight update to the COM Shim Wizard. This is available as a free download here, and the covering article is on MSDN here. The differences Between v126.96.36.199 and v188.8.131.52 are summarized below.
The major difference between v184.108.40.206 and v220.127.116.11 is that v18.104.22.168 was built to install with Visual Studio 2005, whereas v22.214.171.124 installs with either Visual Studio 2005 or Visual Studio 2008, or both. The setup for the COM Shim Wizard now gives you the option to choose which version or versions of Visual Studio to install for. There are 3 additional enhancements to the setup for the COM Shim Wizard v126.96.36.199:
1. The setup disables installation on a per-user basis. This is because installing per-user (and therefore registering to HKCU) causes problems on Vista with UAC turned on, or when running Visual Studio in an elevated process.
2. The custom actions are set to NoImpersonate, so that they work correctly on Vista with UAC on.
3. The setup is formatted so that any error messages are displayed (otherwise they are not visible in Vista, the user just sees Error 2869).
CLR Start Bug
I documented this fix as a community comment added to the MSDN documentation for the COM Shim Wizard v188.8.131.52. Part of what the shim does is to load the CLR: it does this by calling CorBindToRuntimeEx. We test the return from CorBindToRuntimeEx, and if it’s S_FALSE, this indicates that the CLR has already been loaded. In the released version of the shim, if we get S_FALSE, we simply return.
However, there is a scenario where the CLR could already have been loaded but not started. It’s an unusual scenario: it could happen if some other managed code was loaded into the process but never executed. The problem is that the shim code assumes that if the CLR is loaded it is not necessary for us to start it. Of course, if the only other things in the process that load the CLR are all shims created with the COM Shim Wizard, then this assumption would be true – because the first one to load would have loaded the CLR and started it. However, this assumption doesn’t hold if there are other native components that load the CLR but don’t start it.
We fixed this in the code generated by v184.108.40.206 of the wizard by simply removing the test for S_FALSE – this works because we do call Start later on.
Post-build step to copy ManagedAggregator.dll
In v220.127.116.11, a post-build step in the generated shim project copies the ManagedAggregator.dll from the \bin\debug folder unconditionally. We changed this in v18.104.22.168 to copy the dll from the target folder for each project configuration. For example, for a standard debug configuration, it will copy from \bin\debug; but for a release configuration, it will copy from \bin\release.