The problem I refer to as a “dueling
reference” occurs when you setup multiple file-based references to assemblies
from a VS 2005 Web Site Project that are each updated dynamically (using
.refresh files), and which in turn have dependencies on different versions of a
common shared assembly library.
For example, assume your web-site has a
reference to AssemblyA.dll and AssemblyB.dll – which in turn each reference
AssemblyC.dll. This will work without problems if the referenced
AssemblyC.dll is the same version for both AssemblyA.dll and
AssemblyB.dll. But it will cause problems if the AssemblyC.dll being used
is different between the two:
Figure 3
In cases where AssemblyC.dll is different, VS ends up
copying the AssemblyC.dll file twice for each build – since it continually
thinks that the assembly has been updated (once for each reference). This
ends up requiring all references to be recalculated by the compiler, and a full
re-build to occur within the IDE. This will cause build performance to
slow down dramatically, and will cause builds to appear to pause as VS does
this reference recalculation and fix-up on every single build.
How to Fix This Problem
There are a couple of ways to fix this problem:
1) The “most correct” way to fix this issue is to make sure
your class library references are built against the same version of any
dependent assemblies. This is good to-do not just to fix the above
build performance problem, but also because it decreases the likelihood of
introducing hard to figure out bugs in your application (at runtime only one
version of the shared assembly is going to be used –so if you don’t fix this at
least one of your dependent assemblies will end up running against an assembly
it wasn’t built/unit-tested with).
2) The “easiest quick fix” way to resolve this issue is to
modify one or more of your assembly file-based references to not be “automatic
refresh enabled”. You can do this by deleting the .refresh files within
your \bin directory that produce that shared conflict. This will avoid
having VS auto-update the assemblies, and so will prevent the dueling update
conflict altogether. You might find it useful to quickly disable
this behavior by deleting the .refresh files as a stop-gap, and then re-enable
the auto-refresh behavior once you fix the shared assembly conflicts.
Note that VS 2005
Web Application Projects don’t have this dueling reference issue (since
they don’t use .refresh files for file-assembly references). So you won’t
have this build-performance problem with it (instead it will just pick one
version of the shared assembly to use). However, you still want to
be careful about cases where you have two components built against two separate
versions of a shared assembly – since this can still cause hard to understand
behavioral bugs at runtime that end up bypassing your carefully written
unit-tests (which were run against a different version of the shared assembly).
Hope this helps,
Scott
