I have a COM-visible DLL written in C# that I would like to use in a VB6 application. I have two main use cases of the DLL and am wondering when the /codebase
option is applicable and when it is better to register in the GAC.
Use cases:
The DLL will be loaded onto another developers PC and needs to be accessible to the VB6 IDE under the Project > References
menu
The DLL will be loaded onto production machines when the VB6 application is released
Any information on the appropriate use of the /codebase
would be helpful.
Thanks.
What is Regasm Codebase? RegAsm Codebase command line is used to create an entry for codebase in the registry. The codebase entry in the registry specifies the path for the assembly that is not installed on the global assembly cache.
Regasm.exe places the generated type libraries in the current working directory or the directory specified for the output file. Generating a type library for an assembly that references other assemblies may cause several type libraries to be generated at once.
You can run a command-line tool called the Assembly Registration Tool (Regasm.exe) to register or unregister an assembly for use with COM. Regasm.exe adds information about the class to the system registry so COM clients can use the . NET Framework class transparently.
The /codebase option is the exact equivalent of the way you used to register COM servers with Regsvr32.exe. You'll have to pick a specific location for the DLL and the path to that location is written to the registry. That's risky, COM servers have a strong DLL Hell problem since their registration is machine-wide. When you update that DLL then any application that uses the server will be affected. Not often in a good way, this very often breaks an app that was not recompiled to use the updated server.
.NET improves on that by being able to store multiple versions of a DLL as selected by their [AssemblyVersion]. The exact equivalent of the Windows side-by-side cache, the GAC for managed assemblies. So old apps that were not rebuilt will continue to run unaffected, still being able to use the old DLL. That's a good way.
Using /codebase is advisable when you are busy developing the server. You can skip the extra required step that registers the DLL in the GAC. Forgetting to do so is painful, your changes won't seem to work because the test app will load the old version. Regasm will display a warning when you use /codebase, warning you about the DLL Hell potential, you can ignore it.
When you let Visual Studio take care of the registration with the Project > Properties > Build tab, "Register for COM interop" checkbox then you get the exact equivalent of Regasm /codebase /tlb. It is more desirable to do it this way because it also ensures that the old version of the assembly gets unregistered, thus avoiding registry pollution. But VS has to run elevated so it can write to the registry.
Using Isolated COM (aka "registry-free COM") is the best way. It lets you store a copy of the COM server in the same directory as the client program and you don't have to register it at all. That however requires tinkering with the client program, difficult if you don't have any control over the client app or if it is the kind of app that other people like to mess with. Microsoft Office apps for example.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With