> i would encourage you not to do this, if you can avoid it. we've
> fought this several times with nunit which does install itself in the
> gac.
>
The crazy thing is NUnit no longer needs to be installed in the GAC.
You can execute the NUnit GUI from TestDriven.NET and there's no GAC
entry in sight! I've been encouraging the official NUnit distribution
to remove this for a while.
> visual studio has a bad habit of resolving a reference to the version that you
> least expect it to (hint path -- ha!) which can lead to some pretty
> irritating failures.
>
The quite complex way Visual Studio resolves assembly references was
not documented anywhere that I could find. In fact the closest I have
found was in the 'Microsoft.Common.targets' MSBuild file that comes
with .NET 2.0 [1]. The way I deal with this is include the assembly I
want to reference as a project item (this can be a link to a lib
folder).
[1] <!--
The SearchPaths property is set to find assemblies in the
following order:
(1) Files from current project - indicated by
{CandidateAssemblyFiles}
(2) $(ReferencePath) - the reference path property, which
comes from the .USER file.
(3) The hintpath from the referenced item itself, indicated
by {HintPathFromItem}.
(4) The directory of MSBuild's "target" runtime from
GetFrameworkPath.
The "target" runtime folder is the folder of the
runtime that MSBuild is a part of.
(5) Registered assembly folders, indicated by
{Registry:*,*,*}
(6) Legacy registered assembly folders, indicated by
{AssemblyFolders}
(7) Look in the application's output folder (like
bin\debug)
(8) Resolve to the GAC.
(9) Treat the reference's Include as if it were a real file
name.
-->
