Add reference DLL issue in Visual Studio

Hello everyone,

I am using VSTS 2008. I have two projects (both are written in C#) in one solution file. Project 1 depends on the output (DLL2) of project 2. So, in project 1, I am using "References --> Add Reference --> Browse", then find and select the DLL2 generated by project 2.

My question is, I am not sure whether using such method to add reference will result in some my local computer specific file path dependencies? In more details, suppose both of projects are located in folder d:\testprojectsolution (d:\testprojectsolution\project1 and d:\testprojectsolution\project2), I want to make sure that if I copy the whole solution folder d:\testprojectsolution (with the same structures of project1/project2) to other people under different location (e.g. c:\my documents\sampleprpjects\projects), they could build successfully (not dependent on any specific file path on my local machine, for example, no need to find files under d:\testprojectsolution\project2 or something).

If my approach to add reference dependencies could result in some specific file path dependencies, please let me know how to solve this issue. :-)

thanks in advance, George

what is the differences?

George2 2009-04-26 12:04:06

If you add the DLL directly, it'll consider it as a separate entity. It'll not take anything into account. It doesn't care that the reference is in the same solution and should be built *before* this project and will not rebuild the project if the reference is updated.

Mehrdad Afshari 2009-04-26 12:06:13

@Mehrdad, but my question is about file path dependencies, not project build order. :-)

George2 2009-04-26 12:07:40

@George2: I understand. It'll fix that too.

Mehrdad Afshari 2009-04-26 12:13:37

George: Visual Studio uses relative paths where possible. I.e. if you have c:\a\b\c\Binaries, c:\a\b\c\Solution1\Project1 and c:\a\b\c\Solution1\Project2, references from Project1 to Project2 will be "..\Project2" and references to dlls in Binaries will be "..\..\Binaries\foo.dll". So don't worry :)

Anton Tykhyy 2009-04-26 12:13:55

@George2: You can test that it works by moving the project folder to another location on your PC and try opening it in VS. You'll see that it'll work.

Mehrdad Afshari 2009-04-26 12:17:13

@Mehrdad, I have tested it works even if I am using browse approach before asking question. But in my limited knowledge, I can not test every scenario, it is why I come here to ask. So, using add project is always better? It could even handle the issue that -- debug/release project refers the related debug/release project issue?

George2 2009-04-26 12:19:47

@Anton, your advice is using add project or using browse solution?

George2 2009-04-26 12:20:19

When your references are in the same solution, the project approach is preferable as I mentioned above. It'll always work. The browse method *might* add absolute references which can be undesirable.

Mehrdad Afshari 2009-04-26 12:25:48

@Mehrdad, thanks for your advice. I am just curious about differences. Currently, I am using browse and project dependencies to control dependent DLL and build order. I think your solution of using add project is a one-stop solution to solve both DLL dependencies and build order issue. One more question, add project approach could even handle the issue that -- debug/release project refers the related debug/release project issue?

George2 2009-04-26 12:27:48

Yes, it'll handle that too.

Mehrdad Afshari 2009-04-26 12:29:10

@Mehrdad, final question, could you me a sample of my current solution issue -- using browse and project dependencies (other than using add project...)? To be honest, I am not expert, but my existing solution works fine for me for 2 years. So, I want to learn from you more about any potential issue. :-)

George2 2009-04-26 12:31:07

@George2: This is something *built in* Visual Studio build system and I really don't see a reason to circumvent it and do it manually. You can always test using a different project and see this solution works better (indeed, it's been working for me since VS2002). While the way you do it can also work, there are pitfalls to it (as mentioned in comments above, both by you and me). The biggest of which can be debugging issues where u fix the issue and run against a previous version of DLL (can be caused either a debug/release change or wrong dependency order). This will cause lots of headaches!

Mehrdad Afshari 2009-04-26 12:44:10

ansaurus

tags:

views:

answers:

Add reference DLL issue in Visual Studio

related questions