Referencing dll locations
-
I'm using Visual Studio 2010. When I was compiling the execuables that contains 19 different dlls. Each dlls have dependency on other dlls. I just got bumped into a couple of incorrect dlls' date of creation. For example, one dll 'error.dll' is being depended by half of the dlls which consists of error codes and its translations. some of the dlls has error.dll referenced being pointed to the error/bin/debug and others was pointed to error/bin/release. When compiling overall solutions, the exe ended up having the wrong version of error.dll. Is there a better way to control the location of reference files... I mean a way to test or ensure that these references are pointed in their right places to ensure that these dlls are pulled correctly? Thanks... respond back if you have any questions or answers. ~ Ron Boucher
-
I'm using Visual Studio 2010. When I was compiling the execuables that contains 19 different dlls. Each dlls have dependency on other dlls. I just got bumped into a couple of incorrect dlls' date of creation. For example, one dll 'error.dll' is being depended by half of the dlls which consists of error codes and its translations. some of the dlls has error.dll referenced being pointed to the error/bin/debug and others was pointed to error/bin/release. When compiling overall solutions, the exe ended up having the wrong version of error.dll. Is there a better way to control the location of reference files... I mean a way to test or ensure that these references are pointed in their right places to ensure that these dlls are pulled correctly? Thanks... respond back if you have any questions or answers. ~ Ron Boucher
There are two potential solutions that I normally use. If you have the DLL that you are depending on in your solution, use a solution reference to refer to it - right click, Add Reference > Solution. If the reference is to an external DLL, I copy that DLL into a common location (e.g. lib) that exists in the relative path to the solution and all projects use the DLL from that location. The advantage of this is that you can store this in source control, and you can easily sort out versioning issues.
-
There are two potential solutions that I normally use. If you have the DLL that you are depending on in your solution, use a solution reference to refer to it - right click, Add Reference > Solution. If the reference is to an external DLL, I copy that DLL into a common location (e.g. lib) that exists in the relative path to the solution and all projects use the DLL from that location. The advantage of this is that you can store this in source control, and you can easily sort out versioning issues.
-
If you have the source for the dll(s) then the Project reference is a much better solution!
-
If you have the source for the dll(s) then the Project reference is a much better solution!
-
Can you explain why? Is this the step that you're referring to: 1) right click on "Reference" node 2) Add Reference 3) Click on "Projects" tab 4) Select the dlls to reference
If the code is a logical part of your solution then having a solution reference means that a full build should never be out of step.
-
Can you explain why? Is this the step that you're referring to: 1) right click on "Reference" node 2) Add Reference 3) Click on "Projects" tab 4) Select the dlls to reference
Yes, first you add the Project for the dll Assemblies to the Solution and then you do the Project reference(s). The reason I said it is better is that: VS will keep track of whether you're building Debug or Release and make sure the dll is consistent with the rest of the Solution. The correct dll will (can) be automatically copied to the same folder as the rest of the Solution so everything is consistent. The version of the dll Assembly will be consistent in the Solution. Especially useful for keeping track of things in Source Control. (If you modify the dll, then you can be sure the rest of the solution is referencing the one you intend.)
-
Yes, first you add the Project for the dll Assemblies to the Solution and then you do the Project reference(s). The reason I said it is better is that: VS will keep track of whether you're building Debug or Release and make sure the dll is consistent with the rest of the Solution. The correct dll will (can) be automatically copied to the same folder as the rest of the Solution so everything is consistent. The version of the dll Assembly will be consistent in the Solution. Especially useful for keeping track of things in Source Control. (If you modify the dll, then you can be sure the rest of the solution is referencing the one you intend.)