I have two very similar console projects, and two DLL projects. EXE1 calls DLL1 and EXE2 calls DDL2. EXE1 works, but EXE2 does not. I get "the application was unable to start correctly". Could the problem be in the visual studio project settings? I have compared them, but can't find anything.
" EXE1 works, but EXE2 does not. " Doesn't tell us anything. I could make 50 guesses as to the problems cause and come up with a solution for each one. How does it not work? What are the symptoms?
the visual studio Fortran Command Line for the one works contains /module:"Debug/" /object:"Debug/"
The one doesn't work contains /module:"Debug\\" /object:"Debug\\"
I can't figure out where this is set or why they are different. Is it important?
Are you running/debugging these programs from within Visual Studio? Have you tried using a utility such as depends to diagnose? How are the relevant DLLs intended to be located by the operating system loader (Path/current dir/exe dir/etc)? Can the DLL be succesfully loaded dynamically independently of the exe?
I run both EXE's in a console window. The DLL is in the same folder with the EXE. I don't know how to load a DLL independently of the EXE.
The EXE that works has /NODEFAULTLIB:"libc" /NODEFAULTLIB:"Libcmtd"
The EXE that does not work only has /NODEFAULTLIB:"libc"
If I add Libcmtd to the one without it, it won't build because of hundreds of linker errors involving IMSL. Both codes use IMSL.
The combo that is now failing to run was running when I built it last year. When the DLL from today is loaded in Depends, I get the following error message. The DLL I built last year doesn't trigger any errors in Depends. I wish I knew what has changed, but no such luck.
Error: The Side-by-Side configuration information for "c:\users\brian\documents\visual studio 2010\projects\trc-2013\excel directory\DLLUSERTOR.DLL" contains errors. The application has failed to start because its side-by-side configuration is incorrect. Please see the application event log or use the command-line sxstrace.exe tool for more detail (14001).
Anyhow, I am pretty sure the problem is in the DLL, and not in the EXE that is trying to call it. The EXE I build today works with the DLL from last year, but not with today's DLL.
I think that your mentioning EXE1 and DLL1 (which "work fine", whatever that means) is an unnecessary distraction, as would mentioning the thousands of EXEs and DLLs built and used by hundreds of users of VS and IFort.
Concentrate on the pair that are giving problems. Run some EXE utils such as dumpbin /headers, etc., on the EXE2 and DLL2 and read the diagnostic output.
Building with VS amounts to using a gray-box (not quite a black-box, but often quite opaque), so using diagnostic tools and examining build logs is more methodical than comparing to uninteresting successful builds of other projects.
The DLL I built last year with Intel Fortran will work with the EXE built either today or built last year. Why the DLL built today gives the errors I gave earlier is still a mystery. It's probably something very simple (the DLL is one f90 file of about 20 lines of code), but for now I can live with using last year's DLL, and return to this later.
The compile command line is this:
/nologo /debug:full /Od /module:"Debug\\" /object:"Debug\\" /Fd"Debug\vc100.pdb" /traceback /check:bounds /libs:static /threads /c
The link command line is this:
/OUT:"Debug\DLLUserTor.dll" /INCREMENTAL /NOLOGO /MANIFEST /MANIFESTFILE:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUserTor\Debug\DLLUserTor.dll.intermediate.manifest" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /DEBUG /PDB:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUserTor\Debug\DLLUserTor.pdb" /IMPLIB:"C:\Users\Brian\Documents\Visual Studio 2010\Projects\TRC-2013\Lateral Torsion Coupling\DLLUserTor\Debug\DLLUserTor.lib" /DLL
If anyone sees something wrong here, please let me know. The next thing I will probably try is to make a new visual studio project from scratch to build the DLL. I might be asking for trouble by using visual studio, but this DLL is a small piece of a huge project, and VS makes managing the many fortran parts a lot easier for me.