Highlighted
Absent Member.
Absent Member.
3173 views

Managed Calling Native

Jump to solution

Hi,

currently I am playing aroung with the pinvoke ( demonstrating to call a native program from a managed application) sample as follows:

I created a Native DLL Project (SUBS.DLL, containing 3 Programs based on SUB.CBL

I added the generated DLL into the references of PINVOKE.

I get an Error whe calling the DLL , unless I activate the 'Copy Local' Flag in the references properties.
This took me a while to figure out but ok, its  solved.

Now I can run pinvoke from the IDE, but when i start it from the Command Line in the ...\bin\Debug directory, I see nothing but a litany of errors about BadImageFileFormat and Missing Assemblymanifest in SUBS.DLL.

I have attached the project, for anyone who is willing to take a look at it.
- Thanks in advance

I'm shure this is a pretty basic 'newbie' topic, but still I hope someone can point me the right direction.

Also I would like to know whether it is possible to - say compile the 3 programs mentioned above, each one into its own dll and call them without the need of creating a reference in the project file of the calling program.
Actually this is how we operate on AcuCobol, and I would be glad to find a way to keep it so.

regards,
lukas
.

 

0 Likes
1 Solution

Accepted Solutions
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Managed Calling Native

Jump to solution

The problem is that when you call a .dll that resides in a different project then the calling .dll the calling .dll needs to be able to locate the .dll to call.

This can be done either by placing the .dll to be called in the same folder as the calling .exe (which is what Copy Local does) or by setting the PATH environment variable to include the location of the .dll to be called.

If you are running outside of the IDE then you also need to set this up so that the .dll to be called can be located by the calling program.

Please look at the following tutorial on Managed calling native code (p/invoke)

The answer to your other question is that you can create a native project that will create a .dll for each program in the project instead of linking them all together into one .dll.

This is called a multiple output project and can be set under Project-->Properties-->Application tab-->Output to multiple .executables.
Then as long as the program-id is the same as the .dll name you can call it without setting a procedure pointer.

Thanks.

 

View solution in original post

0 Likes
4 Replies
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Managed Calling Native

Jump to solution

The problem is that when you call a .dll that resides in a different project then the calling .dll the calling .dll needs to be able to locate the .dll to call.

This can be done either by placing the .dll to be called in the same folder as the calling .exe (which is what Copy Local does) or by setting the PATH environment variable to include the location of the .dll to be called.

If you are running outside of the IDE then you also need to set this up so that the .dll to be called can be located by the calling program.

Please look at the following tutorial on Managed calling native code (p/invoke)

The answer to your other question is that you can create a native project that will create a .dll for each program in the project instead of linking them all together into one .dll.

This is called a multiple output project and can be set under Project-->Properties-->Application tab-->Output to multiple .executables.
Then as long as the program-id is the same as the .dll name you can call it without setting a procedure pointer.

Thanks.

 

View solution in original post

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Managed Calling Native

Jump to solution

Hello Chris,

thank you so much for the quick and efficient help.

If I only hadthat paper before.

But there is one thing I'd like to ammend:

The errors I described, that when calling the program from the commandline some dependency or assemblymanifest was missing results from the mode of building my dll.

I had activated 'Shared' in the Linker settings.

After switching to 'Dynamic' everything works fine.

I suppose that some other dlls are missing when using the shared model.

Do you know which ones these could be?

Could I expand the PATH to include the missing assemblies and run the solution in shared mode?

thanks,

lukas

.

0 Likes
Highlighted
Micro Focus Expert
Micro Focus Expert

RE: Managed Calling Native

Jump to solution

If you are linking to the shared run--time system it is relying on the current setting of the PATH or COBDIR environment variables in order to locate and load the COBOL run-time system cblrtsm.dll. If you have an old version of cblrtsm.dll from a different Micro Focus product within the PATH or it locates a 64-bit version when you are running a 32-bit application then this could account for the error that you are seeing.

You would not see the same error when running under the IDE as it locates the run-time system using the proper registry entries for the product you are using.

Likewise, when you turn dynamic linking on your application also will look in the system registry under the appropriate product entry to locate and load the COBOL run-time system instead of relying on the setting of PATH.

It sounds as if your system PATH does not include the bin folder for the Visual COBOL product which by default on a 64-bit system would be located at c:\program files (x86)\micro focus\visual cobol\bin.

Thanks.

0 Likes
Highlighted
Absent Member.
Absent Member.

RE: Managed Calling Native

Jump to solution

Hello Chris,

It took me a while to solve that. I checked all your recommendations, but  to no better.

Finally I tried to run my program from the "32 Bit Visual Cobol Prompt" provided in the system menu.
It works well there.

Analyzing the differences I found out that I had modified my PATH Variable to point to the correct Directory, but I provided double Quotes because the path contains spaces. like this:
SET PATH=C:\Program Files\HP\NCU;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;"C:\Program Files (x86)\Micro Focus\Visual COBOL for Visual Studio 2012\bin\";C:\BATCH;
This is totally normal in MSWindows environments and Programs from that Directory are found when executed at the Commandline. Obviously the Cobol Runtime does her own parsing of the PATH variable which lead to my Problems.

Eliminating the double quotes or using the 32Bit Cobol Prompt solved my Problems

0 Likes
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.