- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have VS2005 and IVF 11.1.054.
I have a solution consisting of a C++ main program and Fortran DLL.
I make the Cmain project dependent on the DLL.
I have added the DLL.LIB file to the C++ project.
Under "project..properties...configuration properties...linker...general..additional library dependencies' I have added a path to the DLL.
I am trying the debug configuration first.
The solution builds OK.
When I try 'Start without debugging' I get a message box saying
"This application has failed to start because Dll1.dll was not found. Reinstalling the application may fix this problem."
I am at a loss to understand how, having made the Cmain dependent on the DLL project etc, the Cmain .EXE cannot find the DLL.
Why is this and how to automatically direct the Cmain program to the dll folder?
update: I have copied the DLL to the Cmain /debug/ folder containing the .EXE file and now the Cmain program executes Ok and finds the DLL. Why do I have to do this?
I have a solution consisting of a C++ main program and Fortran DLL.
I make the Cmain project dependent on the DLL.
I have added the DLL.LIB file to the C++ project.
Under "project..properties...configuration properties...linker...general..additional library dependencies' I have added a path to the DLL.
I am trying the debug configuration first.
The solution builds OK.
When I try 'Start without debugging' I get a message box saying
"This application has failed to start because Dll1.dll was not found. Reinstalling the application may fix this problem."
I am at a loss to understand how, having made the Cmain dependent on the DLL project etc, the Cmain .EXE cannot find the DLL.
Why is this and how to automatically direct the Cmain program to the dll folder?
update: I have copied the DLL to the Cmain /debug/ folder containing the .EXE file and now the Cmain program executes Ok and finds the DLL. Why do I have to do this?
Link Copied
4 Replies
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
In order for the linker to find the export library DLL.LIB, the library has to be accessible through the library search path : the value of the %LIB% environmental variable, possibly with added paths specified through the IDE, as you have done.
Likewise, for the runtime to load the DLL when it is needed, the dynamic library DLL1.DLL has to be accessible through the execution path: the Windows default executable search path, plus the value of the %PATH% environmental variable, possibly with added paths specified through the IDE, which you probably have not done.
Thus, successful linking does not imply successful execution.
It is even possible to perform a successful link to an import library corresponding to a non-existent DLL; for example, one can decide upon the formal arguments to the DLL routine, write a suitable INTERFACE in the caller, set up a .DEF file with the correct name decoration and produce an .EXE file for the caller, all without a single line of code having been written for the to-be-called DLL.
Likewise, for the runtime to load the DLL when it is needed, the dynamic library DLL1.DLL has to be accessible through the execution path: the Windows default executable search path, plus the value of the %PATH% environmental variable, possibly with added paths specified through the IDE, which you probably have not done.
Thus, successful linking does not imply successful execution.
It is even possible to perform a successful link to an import library corresponding to a non-existent DLL; for example, one can decide upon the formal arguments to the DLL routine, write a suitable INTERFACE in the caller, set up a .DEF file with the correct name decoration and produce an .EXE file for the caller, all without a single line of code having been written for the to-be-called DLL.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I solved my problem by adding a post-build event to the .DLL project to copy the .DLL to the main .EXE configuration folder using the command line:
copy $(OutDir)\dll1.dll "$(SolutionDir)cmaintest\$(ConfigurationName)\dll1.dll"
I found I had to put the target path in quotes as it contains blanks which otherwise caused the command to fail.
copy $(OutDir)\dll1.dll "$(SolutionDir)cmaintest\$(ConfigurationName)\dll1.dll"
I found I had to put the target path in quotes as it contains blanks which otherwise caused the command to fail.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Alternatively in your DLL projectunder the Project->Properties->Linker->General->OutputFile you can specify the target directory(plus the dll filename) to be the directoryof the exe.
Les
Les
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Les's suggestion is much better -- otherwise, you might end up actually debugging one version of the dll, but looking at the code of another. Simplery still, leave "Output File" alone and change only
Project->Properties->General->Output directory
to that of the exe (preferably, in relative syntax, e.g. "..\..\bin" , so that you can copy the whole thing elsewhere one day).
Project->Properties->General->Output directory
to that of the exe (preferably, in relative syntax, e.g. "..\..\bin" , so that you can copy the whole thing elsewhere one day).
Reply
Topic Options
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page