A little COM can really mess up a XCOPY day

I ran into an issue today on a product my team is developing due to a limitation in C#. Some may say it's a feature not a limitation. Like the fact that Java at one time didn't have enums. But I digress.

The ability to XCOPY a .NET application to a new computer along with its dependent binaries, and just run it is one of the coolest aspects of .NET. Especially given the experiences we've all had with older native technologies like C++ and COM. COM in fact, is the issue in my case.

Now, .NET can work with COM components just fine. A little COM Interop via a wrapper generated by VS.NET 2005 when it's added to a project, and voila! you're in business. Looks and feels just like a managed .NET object and not a native one.

There's only one problem.

To use a .NET COM Interop wrapper, the COM component has to be registered. When you create an instance of the COM Interop wrapper class, it actually does some magic and creates an instance of the underlying COM object. To do that, it has to do the same things that any native C++ application had to - namely use CoCreateInstance to ask Windows to look up information about the object in the registry and then create it.

No issues yet.

Of course, this depends on the COM component being registered - that is, having its entries added to the HKEY_CLASSES area of the registry. Normally this happens by using REGSVR32.EXE that comes with Windows to ask the component to register. In C++, it would have been snap also - a call to LoadLibrary, GetProcAddress and FreeLibrary would have sufficed. Asking GetProcAddress to fetch the function DllRegisterServer and then calling that function would have the COM component do its thing to register itself. Basically how all COM components manage this.

Back to the XCOPY intersection.

When copying files to a new computer, at what point does the COM component get registered? Answer - it doesn't. At least not automatically. My problem arose at this point since C# doesn't permit calling functions (event Interop ones) via a function pointer. It's that limitation, ..er feature thing again. After some head scratching, I wrote some code that registered my COM component on-demand and allowed me to keep my nice little XCOPY mode of deployment.

Next time I'll show you what I did.

And no, I didn't resort to C++ to do this.

Posted by Mark M. Baker at 05:05 PM  Permalink