Honored Contributor.
Honored Contributor.

Clarification re: native calling managed in production environment

Please clarify...

The article "Calling Managed COBOL from un-managed code" (with the VCCOM.zip samples) discusses using the Regasm tool to register the appropriate "com server" assembly for a production environment.  (In this case, the production environment is a classical windows-based client-server environment using Win7 workstations and Windows server 2008 server.)  This article further provides a link to Microsoft doc related to Regasm.exe.  The article gives examples of the regasm command line which shows using the "/codebase" option.  When reading the linked-to Microsoft doc, it says that if you use the "/codebase" option, then the assembly must be a strong-named assembly.  Is this true?  Do we have to use the Microsoft Strong Name tool as well?  Also, there is some confusion related to having to use the Microsoft GAC (or not).  Please clarify. 

1 Reply
New Member.

RE: Clarification re: native calling managed in production environment

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.




            type="win32" name="myfile" version="" />



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.


The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.