Microsoft is hinting in this article, Automatic Updating of Visual Basic Applications, a practice that should enable COM DLL access without registering the DLL.
I knew about this already but this has me thinking. Over the last year and a half I have been working heavily with a CRM product that supports dynamic deployment of application plug-ins via a database BLOB record. The plug-ins are "self-contained" in that they introduce scripted content, not binary content. This is changing with the new release, however, which supports .NET Extensions.
One of my disappointments with .NET Extensions, however, is that .NET is not appropriate in the COM-based world that the product is. VB6 COM DLLs are far more appropriate. But the problem with VB6 COM DLLs is that they must be registered. That fact has caused the product development team to hesitate with supporting custom COM DLL deployments (except in very special circumstances, namely the OLE-DB provider extensions).
So I have a little pet project in mind that I might consider tackling. It consists actually of two components:
- A command-line tool (with an optional GUI front-end) that will take a COM object, push it through the .NET SDK’s RCW generator, but then wrap that output (the COM object and its Interop file) into an "auto-install" assembly, embedding the COM object as a resource. This containing assembly would then auto-extract and expose the COM object through the CLR.
- Another command-line tool that will take a managed assembly with its CCW and generate a native DLL with the CCW-wrapped managed assembly embedded into the DLL.
Someone at my former place of work (a certain S. Carnie) came up with an astounding solution after a few nights’ work of not only making a C# / VB.NET managed assembly a true COM object by wrapping it in a C++/CLI DLL–but also packaging up all the dependencies of the managed assembly (even the debug database!) and stuffing it all into one DLL for easy deployment. When a COM client calls upon this wrapper, the embedded resources are extracted and loaded and then called upon. This is why I love software!!
The catch with his solution is that AFAIK (I still have not examined his public source code) the COM interfaces were predefined. I would want to accomplish the same thing but not make them predefined. Essentially, I would want all public members of the CLR assembly to be COM-exposed in the native DLL.
This would likely entail some code generation and auto-compilation, in which case it wouldn’t be a small project. Even so, I know it’s doable, and I tend to wonder why Microsoft didn’t already do it.