We have a problem with our project files, which is annoying.
Example:
We have a solution with projX and projY, which reference the assembly log4net.
Say, e.g. somebody moves the assembly file and only updates the reference in projX + then commits without discovering the missing assembly – then the reference goes missing in projY.
The next time I do a checkout and open the solution the projY has the reference correctly marked by VS2010 as missing, with a little exclamation mark. So far so good. 🙂
Problem:
Now if I do Build of the solution then the assembly reference is magically updated in projY to point to projX’s BIN folder! (In this case projX has to be build BEFORE projY)
It appears that VS2010 searches our solution tree and adds the assembly automatically if it can find a matching one.
Nice feature, but also a bit dangerous and very misdirecting. For example the assembly might end up having a path which points to another projects bin folder.
Question:
Is there any way to disable this behaviour and just get a compile error, which prevents the build?
Notes:
- We shifted to using NuGet recently.
- We have defined our own output folder -> files are not placed in Bin\Debug but in ..\output.
[EDIT]
Updated the example for more clearity.
[EDIT]
Searching the web for a solution I found this articale which describes a related problem, where VS2010 also auto adds references but from in this case from the GAC. Our assemblies are NOT in the GAC. http://blog.scrappydog.com/2010/07/bug-tfs-2010-outsmarts-itself-and-auto.html
[EDIT]
Tried fixing this using a Reference Path in the project. The idea was that VS would search the Reference Path first and project bin folders second. But no luck. It still takes the assemblies from the output folder.
No, there is no known workaround about this.