Do you have references issues with Visual Studio 2008 and C#?

Question

I'm working on a project and it seems that every time someone checks out the project from source control to build it on their local box they have issues building because references are no longer resolved.

I can't figure out if it's a configuration issues or a Visual Studio 2008 issue. Is anyone else having this problem? If so, is there something you can do to fix this issue?

Note: it might have something to do with explicit paths to the DLLs being referenced or how they are referenced ... I'm not quite sure.

Answer 1

Typically I see this with one of three things

1. Packages on Machine A, not on Machine B
2. Things in the GAC (Global Assembly Cache) on machine A, not in Machine B
3. Packages not checked into source control

Visual studio typically handles relational pathing well, and I've not had it just be a path issue.

Also make sure you are NOT checking in .SUO files and .csproj.user. These will both monkey with references sometimes.

Answer 2

Start looking in your .csproj files. We had this problem years ago, but soon learned that it was more operator error than anything else. Specific items to look for are: <HintPath> and <ProjectReference> .

Answer 3

Yes, your problems could definitely be caused by the paths to your referenced DLLs. Have a look at the properties of the DLL in the References folder of the project (right click on the reference item in your Visual Studio solution and select Propertiers) to see the path that is being used for the DLL. To get around this problem one option is to make sure everyone has the same path on their local drive to the referenced DLLs. You can also use the Reference Paths page on the properties of your project to add additional reference paths to the projects.

Answer 4

请检查是否有人<ReferencePath> under <propertygroup>中的任何csproj.user文件中意外提交/签入了其本地路径

Answer 5

It sounds like the referenced DLLs are not checked into source control - I put all external dlls in a lib folder under the project root and reference those. I've never had a problem with Visual Studio resolving the relative paths correctly.

Answer 6

1. References to your own code in same solution should be "Project References". Never add these as references to the DLL directly. For your own/in-house code, add as much as is practical to the solution. Otherwise take strategy 2C.
2. References to other code should be discussed and a strategy chosen for each type of reference. You have a couple of options:

a. Add the DLL directly as part of your solution, perhaps in a LIB directory. Check it into source control. Every team member will have a consistent experience.

b. For 3rd party components, everyone should probably run the vendor installation package with consistent installation paths, etc. (Many 3rd parties install to the GAC, so this becomes part of the reference. Otherwise it would be c:\\Program files\\etc etc)

c. Publish the DLLs to a shared directory, ie a network share. Reference DLLs from this path only. Ensure Copy-Local is true.

Verify the strategy has been followed by reviewing the CSPROJ file XML for tags such as ProjectReference and HintPath.

Finally, each team member should be aware of this. If anyone does something different, then you will feel the pain again and again with each new "Get Latest".