Clarification re: native calling managed in production environment

Please clarify...

The article "Calling Managed COBOL from un-managed code" (with the 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. 

  • 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 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'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.