Can't call a fortran dll made in VS2008 from an application (also vs2008, c#)

[ove_svennbladitt_com]

Hello,

I can't call my fortran dll (made in vs2008 sp1) from my vs2008 c# application. I get an error from Microsoft Visual C++ Debug Library with code R6034, an application has made an attempt to load the C runtime library without using a manifest.

I tried to install visual C++ redistributable package but it did not help..

Anyone?

regards,
-ove svennblad

[Steven_L_Intel1]

Haven't seen this one - but try setting the Fortran project property Libraries > Use Run-Time Library to "Multithreaded" (not Multithreaded DLL") and rebuild.

[ove_svennbladitt_com]

Quoting - ove.svennbladitt.com

Hello,

I can't call my fortran dll (made in vs2008 sp1) from my vs2008 c# application. I get an error from Microsoft Visual C++ Debug Library with code R6034, an application has made an attempt to load the C runtime library without using a manifest.

I tried to install visual C++ redistributable package but it did not help..

Anyone?

regards,
-ove svennblad

Hi Steve,

Thanks for your answer.
I followed your suggestion, but got into another problem.
Got "LNK2019: unresolved external symbol _Main__ referensed in _main in file libifcoremt.lib"

So, found some hints in another thread and
1. added libifcoremt.lib as a source file to my solution
2. wrote !DEC$ OBJCOMMENT 'lib:libifcoremt.lib' in a source file
3. added path for this lib to Properties/linker/input/additional dependencies

but I still got the same error, LNK2019..

regards,
ove svennblad

[Steven_L_Intel1]

I would not recommend any of those additional steps you took. There should be no references to _Main__ in a DLL. Are all of the sources in your DLL FUNCTIONs and SUBROUTINEs? You can't have a main program in a DLL (or rather, you shouldn't).

Undo those steps you did. Rebuild the DLL. If you don't mind, attach a ZIP of the DLL to a reply here, as well as the buildlog.htm from doing a "rebuild" on the DLL project. If you can't attach the DLL, download Dependency Walker, run it, drag your DLL onto its window and then do File > Save to save a .dwi file. Attach the .dwi file.

[ove_svennbladitt_com]

Hi Steve,

All files in my dll are subroutines or functions (most of them are old ones from the 90s and even the80s)
I did undo the steps you recommended, got the LNK2019 message again and no dll was generated, so I could not load the dll into dependency walker.
Included is the htm buildlog file

regards,
-ove

[Steven_L_Intel1]

Interesting. Please repeat this after setting the property Linker > Show progress messages to "Show all progress messages".

You may also want to take a look at the warnings - especially the one about MIN0.

[ove_svennbladitt_com]

Ok, included is the new buildLog

regards,
-ove

[Steven_L_Intel1]

I'm baffled so far. Are you willing to attach a ZIP of the DLL project (after a Build > Clean)?

[ove_svennbladitt_com]

Hi Steve,

I finally managed to compile my dll. I played around with compiler settings and changing LinkeradvancedResouce only Dll from Yes to No did the trick. I have not explicitely set an entry point in the option above this one and therefore this "Resource only Dll" flag was set to yes...

Is a DLLEXPORT attribute enough to define an entry point to my dll (don't have to add anything into compiler options)? When is the option Resource Only used?

regards,
-ove

[Steven_L_Intel1]

I was unfamiliar with this option, but looking at the documentation explains exactly why you had the linking problem. The default for this setting is No - you must have changed it to Yes at some point. The MS documentation says:

The /NOENTRY option is required for creating a resource-only DLL.

Use this option to prevent LINK from linking a reference to _main into the DLL.

The DLLEXPORT directive is all you need.

[ove_svennbladitt_com]

Ok, thank you very much for your help and time!

regards,
-ove

[Les_Neilson]

"A resource-only DLL is a DLL that contains nothing but resources, such as icons, bitmaps, strings, and dialog boxes. Using a resource-only DLL is a good way to share the same set of resources among multiple programs. It is also a good way to provide an application with resources localized for multiple languages"

ie there is no code in a "resource only dll

Les

[Steven_L_Intel1]

I must admit that I am still confused by this option - under what circumstances would you want a DLL to have a reference to a main entry point?

[Jugoslav_Dujic]

Quoting - Steve Lionel (Intel)

I must admit that I am still confused by this option - under what circumstances would you want a DLL to have a reference to a main entry point?

"main entry point" here was meant to be "DllMain" (aka DllEntryPoint). Resource-only dlls don't have one (however, they must be loaded using LoadLibraryEx(LOAD_LIBRARY_AS_IMAGE_RESOURCE) ).

[Steven_L_Intel1]

The MSDN documentation refers to a _main entry point, and that's what was being emitted here. I know about DllMain, but that would be just a normal exported routine name and not require the linker to emit a reference for it.

The only thing I can think of is if you wanted to treat a DLL as an EXE.

[Les_Neilson]

Quoting - Steve Lionel (Intel)

The MSDN documentation refers to a _main entry point, and that's what was being emitted here. I know about DllMain, but that would be just a normal exported routine name and not require the linker to emit a reference for it.

The only thing I can think of is if you wanted to treat a DLL as an EXE.

Since the dll had code within it but was flagged as a resource only dll possibly Visual Studio got confused ?which is not very hard to do :-(

Les