Linking DLL's
-
joeller wrote:
In my opinion, it is not good practice to include dll's to third party applications directly in your project's directory, (although I know that .Net managed applications do that with referenced third party namespaces). I am also not comfortable with adding third party dll's directly to the system32 directory. I feel that the calling application should be able to refer to the dll in the third party application's own bin folder. I would appreciate some advice on how to make this happen in Visual C++ if possible.
Welcome to DLL hell. Even Microsoft calls it that. :) Adding the path to the PATH environment variable is the way to do it but I believe you'll need a full path, not a relative path. It doesn't work the same way as the path settings in the Visual Studio environment, where paths are put together based on your project paths.
-
The "directories for executable files" setting has nothing to do with the DLL search path. That dir list is where the IDE will look for executables that get run in your build rules. You'll need to do one of three things 1. Change the app's code to load DLLs from the bin directory (this will mean changing from implicit loading to using
LoadLibrary()) 2. Put the DLLs in the same dir as the app. 3. Change the machine's PATH variable and add your bin directory (not reliable, as the user can always change the PATH himself)--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ
From original Post: "When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin")." I neglected to mentioned that when this was done, everything worked as designed. "But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed." That was the full path to the specified folder. I tried your #2 and it works. That is what everyone is doing now and I would like to get away from that. I tried your #3 (see above) and it did not work. I tried #1 several weeks ago. I don't remember whether it worked or not. As I recall it required the entry of the path to the dll in the code. However I am trying to avoid that because that would necessitate each developer putting the dll project on their machine in the same location for the code to work. In this non-optimum development environment, each developer uses source safe to get latest version and installs the projects in whatever location they so desire. They then use the VC++ Directories property page to set the linkages to the other header and library files that are needed. They have been copying the dlls into the project directory. Since I am only a contractor for this one project I do not want to tell them to revise their way of doing business. So I was trying to find means by which they could access dlls without copying them into the project directory. Of course this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.) I never liked that resolution for dll hell because it requires that any new version of a dll (stuff like bug fixes and service packs), now need to be copied to every application that uses it. For very general reusable code,that is used in many places, (like this is going to be,) that means quite a lot of copying and checking. What about the possibility of using the command line additional options under Configuration\C/C++ folder s of the project property pages? E.R. Joell MCSD MCDBA
-
"Adding the path to the PATH environment variable is the way to do it but I believe you'll need a full path, not a relative path." Quite right which is what I did. no joy.
Even after reboot (maybe even just re-logon)? That's worked since before Windows :)
-
From original Post: "When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin")." I neglected to mentioned that when this was done, everything worked as designed. "But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed." That was the full path to the specified folder. I tried your #2 and it works. That is what everyone is doing now and I would like to get away from that. I tried your #3 (see above) and it did not work. I tried #1 several weeks ago. I don't remember whether it worked or not. As I recall it required the entry of the path to the dll in the code. However I am trying to avoid that because that would necessitate each developer putting the dll project on their machine in the same location for the code to work. In this non-optimum development environment, each developer uses source safe to get latest version and installs the projects in whatever location they so desire. They then use the VC++ Directories property page to set the linkages to the other header and library files that are needed. They have been copying the dlls into the project directory. Since I am only a contractor for this one project I do not want to tell them to revise their way of doing business. So I was trying to find means by which they could access dlls without copying them into the project directory. Of course this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.) I never liked that resolution for dll hell because it requires that any new version of a dll (stuff like bug fixes and service packs), now need to be copied to every application that uses it. For very general reusable code,that is used in many places, (like this is going to be,) that means quite a lot of copying and checking. What about the possibility of using the command line additional options under Configuration\C/C++ folder s of the project property pages? E.R. Joell MCSD MCDBA
joeller wrote:
...this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.)
Really? I haven't seen that behavior. Where is this documented?
-
Even after reboot (maybe even just re-logon)? That's worked since before Windows :)
-
You may have seen this already but if not, maybe it will help... Dynamic-Link Library Search Order[^]
-
joeller wrote:
...this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.)
Really? I haven't seen that behavior. Where is this documented?
That was two years ago, I no longer remember were we read it. We were creating an ASP.Net application and we noted that after each build there was a copy of all the dll's we were using in the project's bin directory. We checked in out, and found that this behavior was as designed. Supposedly it was to allieviate the issues of DLL Hell to which the first replier referred to, as the application would always have the the version dll with which that it was compiled to work. The other advantage was that it facilitated the use of XCopy to deploy your application without worrying whether the dll that was needed was registered on the machine to which you were deploying. (The customer liked it because he did not have to register third party dll's on his server.) I found it irritating because I had come from a VB 6.0 background where you only had to set binary compatibility then you could replace the dll without having to re-register it. I ran a google check before answering this entry. But I was not able to locate the place I read it. Could have been a book. Could have been 4GuysFromRolla. Found an entry in MSDN about referencing assemblies. Found a forum entry from a guy that found out the same thing we did. (He asked the question then posted the answer himself when no one answered him.) I am sorry I can't give you a better answer. E.R. Joell MCSD MCDBA
-
That was two years ago, I no longer remember were we read it. We were creating an ASP.Net application and we noted that after each build there was a copy of all the dll's we were using in the project's bin directory. We checked in out, and found that this behavior was as designed. Supposedly it was to allieviate the issues of DLL Hell to which the first replier referred to, as the application would always have the the version dll with which that it was compiled to work. The other advantage was that it facilitated the use of XCopy to deploy your application without worrying whether the dll that was needed was registered on the machine to which you were deploying. (The customer liked it because he did not have to register third party dll's on his server.) I found it irritating because I had come from a VB 6.0 background where you only had to set binary compatibility then you could replace the dll without having to re-register it. I ran a google check before answering this entry. But I was not able to locate the place I read it. Could have been a book. Could have been 4GuysFromRolla. Found an entry in MSDN about referencing assemblies. Found a forum entry from a guy that found out the same thing we did. (He asked the question then posted the answer himself when no one answered him.) I am sorry I can't give you a better answer. E.R. Joell MCSD MCDBA
Cool thanks. A proper entry in the PATH environment variable should work. It's really strange that it doesn't work for you. Mark
-
Cool thanks. A proper entry in the PATH environment variable should work. It's really strange that it doesn't work for you. Mark
-
From original Post: "When I built this application on another machine with VS 2005, the project properties page under Configuration Properties\Debugging had an entry called "Evironment" whereby I could enter the relative path to the YadaYada\bin directory; (Set PATH="..\YadaYada\bin")." I neglected to mentioned that when this was done, everything worked as designed. "But I was not able to find any equivalent entry on the property pages in Visual Studio .Net (2002). I manually added the path to the dll to the machine's "PATH" environment variable but it made no difference. When I copied the dll to the project's folder however everything worked as designed." That was the full path to the specified folder. I tried your #2 and it works. That is what everyone is doing now and I would like to get away from that. I tried your #3 (see above) and it did not work. I tried #1 several weeks ago. I don't remember whether it worked or not. As I recall it required the entry of the path to the dll in the code. However I am trying to avoid that because that would necessitate each developer putting the dll project on their machine in the same location for the code to work. In this non-optimum development environment, each developer uses source safe to get latest version and installs the projects in whatever location they so desire. They then use the VC++ Directories property page to set the linkages to the other header and library files that are needed. They have been copying the dlls into the project directory. Since I am only a contractor for this one project I do not want to tell them to revise their way of doing business. So I was trying to find means by which they could access dlls without copying them into the project directory. Of course this is the .Net solution. (Where the dll's for each name space that is referenced in your project is copied to your bin directory.) I never liked that resolution for dll hell because it requires that any new version of a dll (stuff like bug fixes and service packs), now need to be copied to every application that uses it. For very general reusable code,that is used in many places, (like this is going to be,) that means quite a lot of copying and checking. What about the possibility of using the command line additional options under Configuration\C/C++ folder s of the project property pages? E.R. Joell MCSD MCDBA
The environment setting in the project options only affects the app when you run it from the IDE, and even then all it's doing is modifying the PATH variable. This won't have any effect when the app is run on other machines.
--Mike-- Visual C++ MVP :cool: LINKS~! Ericahist | PimpFish | CP SearchBar v3.0 | C++ Forum FAQ