I use a lot of managed code (C#) from unmanaged code (Net Express) and depending on your application I would try and stay away from registering anything.
Some of our managed code is COM aware and is NOT strong named and instead of registering the component I enter the dependency in the manifest of the main executable.
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32" name="myfile" version="1.0.0.0" />
</dependentAssembly>
</dependency>
You must also have a manifest in the managed code, known as activation code.
When you executable is launched, the manifest is interrogated, the dependencies read. When the dependency is located it fires the activation code. Failure in this process results in a 'Side by Side' error.
The benefits of this method allow you to have multiple versions of your product running on the same machine with different versions of the COM components.
My managed code components are C#.....so I don't have any issues.
If your managed code components are Visual COBOL and your unmanaged code is Net Express my guess is there would probably be an issue with the runtime (I haven't tested that). The Net Express runtime would be loaded then trying to run a Visual COBOL COM component in the same process would probably force an OOPS error about the dynamic binding.
What if you don't have an execuatble?
You could also create a managed code component with unmanaged entry points, then instead of treating it as a COM component you would do a LoadLibrary, get pointers to the methods, then execute them.
This removed the need to register components, again allowing you more flexibility.
If all else fails.......you'll have to do a regasm /codebase yourfile.dll
My summary:
It doesn't have to be strong-named
Rather manifest than register
Unmanaged entry points is another method you could consider.
Neil