Assembly Search Paths

[Jamie Cansdale]

This question is related to the 'Revisiting the GAC Issue' thread.

Here is an extract from:
\Windows\Microsoft.NET\Framework\v2.0.50727\Microsoft.Common.targets

It's the list of locations C# and VB projects will use to resolve
project references.

<!--
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.
-->
<AssemblySearchPaths Condition=" '$(AssemblySearchPaths)' == '' ">
{CandidateAssemblyFiles};
$(ReferencePath);
{HintPathFromItem};
{TargetFrameworkDirectory};
{Registry:$(FrameworkRegistryBase),$(TargetFrameworkVersion),$(AssemblyFoldersSuffix)$(AssemblyFoldersExConditions)};
{AssemblyFolders};
{GAC};
{RawFileName};
$(OutputPath)
</AssemblySearchPaths>

My question is, which assembly search path are you?

I tend to create a project item link to any dependencies inside my
projects (e.g. 'Add > New Item > Existing Item... > Add as Link').
Because the assembly is then part of the current project - this makes
me a (1).

If you don't add an item link, you're probably using the hintpath
which is associated with your reference - making you a (3).

Which search path # are you?

Thanks,
Jamie.

--
http://www.testdriven.net
http://twitter.com/jcansdale
http://weblogs.asp.net/nunitaddin

[Charlie Poole]

Who are you asking? About what projects?

[Jamie Cansdale]

> Who are you asking?
>
Anyone, but in particular - people on the 'Revisiting the GAC Issue' thread.

> About what projects?
>
Any projects you work on.

Regards,
Jamie.

[Charlie Poole]

OK... I wasn't sure if you meant NUnit itself.

Charlie

[Simone Busoli]

Honestly this is something new to me, and quite interesting, I always thought it was sort of a mystery where VS would lookup references.

Are you saying that by linking an assembly from a project makes it the primary lookup location? You still have to add a reference to it, I guess.

Anyway, the way I always do it is with "Add Reference", which I think by default when you reference an assembly from the file system introduces a HintPath, thus making me a (3).

[Sébastien Lorion]

same as you, ie #1

Sébastien

[Simone Busoli]

Seb, would you expand on how you do that exactly?

[Sébastien Lorion]

Hum, I read too quickly .. :-p I thought Jamie was talking about
project references. I am not sure exactly how his setup is and am
curious about it.

To reference projects inside the same solution, we use a project
reference, which would still be a #1. For external libraries, we will
use the .NET tab if possible, otherwise the browse tab. In the case
where we want to use an external, but want to limit its use to this
single project (e.g. we want to benchmark against another library that
we will never use otherwise), then we create a lib folder inside the
project, put the dll there and set the option "Copy to output
directory" to "Do not copy". We then reference directly that library
with the option Copy Local set to True.

There are some issues with Copy Local set to true (e.g. compilation
time), but so far, it has not affected us in a dramatic way even on
medium-large projects (> 1,000,000 loc). The one thing that takes ages
to compile are web projects.

For our framework, we have a project for each logical component, but
we use ilmerge to get a single assembly to deploy. Lately ilmerge is
crashing when merging one particular component and hopefully, we will
get that fixed soon ...

Sébastien

[Simone Busoli]

Yes, actually I'm doing the same as you do, it's the approach Jamie talked about that I'm interested into. Not that I know whether it could benefit or not, but I'm curious since it sounds like a new approach to me.

[Jamie Cansdale]

> Are you saying that by linking an assembly from a project makes it the
> primary lookup location? You still have to add a reference to it, I guess.
>

Yes, exactly.

It means reference this exact assembly and never be overruled by a
.user file (which can contain reference paths). Because .user files
generally aren't checked into version control - doing it like this
ensures that my local build is exactly the same as from my build
server (where there are no .user files).

If you're aware of .user filed and hintpaths, doing it this way is
perhaps overkill. I got into the habit of doing it like this with
VS2002/2003 (when there was no Microsoft.Common.targets file to see
exactly what was going on).

These days using a hintpath and ensuring that 'Specific Version' is
set to 'False' is probably good enough. Old habits die hard. ;-)

Regards,

Jamie.

--
http://www.testdriven.net
http://twitter.com/jcansdale
http://weblogs.asp.net/nunitaddin

[Simone Busoli]

But where do you reference the nunit.framework.dll from? I mean, when you perform an "Add Reference", you cannot reference it from the lib folder which is local to the project because it's a linked file and won't appear in the dialog, so you'll have to reference it from its original location, the same the one under the lib folder links to, right?

So what do you achieve? That the one under lib folder has precedence since it's (well, its link is) local to the project?