Home > Blogs > barry

Assembly Reference Resolving in Visual Studio.

Posted: Friday, October 29, 2004 4:38 PM by Barry Gervin
Filed under: , , , , ,

I got a question today about a problematic assembly references during a build of a large project.

Visual Studio projects have a user file (*.csproj,user, *.vbproj.user) that stores a “References Path”. You can edit this list of paths in your project properties dialog and it works like a PATH variable.

The twist comes in when you add a reference to a project. The IDE creates a relative formed path to the assembly you picked in the add reference dialog and places that as a “hint path” in the .csproj/.vbproj file.

So imagine you have some carefully crafted hint paths in your project file references, and no references paths in your user file. It's still possible, for your assembly to not be found where you expect it.

Did you know that VS.NET will automatically add References Paths for you as part of it's build process. Let's say you have a list of references in your project. As VS.NET iterates through the list of them one at a time, it will first check the references path. If the assembly is not found, it will use the hint path. If it finds it with the hint path - it will take the fully qualified path to that assembly - and put it in references path of your user file. When it gets to the next assembly it will check all those references paths - including the one it just automatically added.

What happens if you have multiple copies of your referenced dll hanging around? It could find one other than the one you referenced in your hint path.

This is all pretty rare to happen, but if you are like some folks who use Visual Studio itself as your build server (not NAnt) and as a matter of practice you delete your .user files as part of that build (with the predefined reference paths), you could find yourself in hot water. The only solution in this mixed up process is to make sure you don't have multiple copies/versions of your referenced assemblies lying around. Or better yet, use NAnt.

Comments

  • Barry Gervin October 18, 2005 6:10 AM

    Hi,
    How does using NAnt solve this problem? I am using NAnt solution task and have run into exactly the same manhole.
    My project has a hintpath to a relative path for v 2.3.1.1, but on a build one project seems to be finding 2.3.1.0 from the GAC (2.3.1.1 is present in the GAC also). As a result the component licensing fails at runtime.
    I have spent more than a day hunting this down but to no avail... Any ideas ?
    The source is checked out and all files not in the view are deleted prior to a build.

  • Barry Gervin November 29, 2005 5:44 AM

    use the <solution> tag and embed the <assemblyfolders> tag:

    <solution solutionfile="${Solution.Filename}" outputdir="${Build.OutputFolder}" configuration="${Solution.Configuration}">
    <assemblyfolders>
    <include name="${Build.OutputFolder}"/>
    </assemblyfolders>
    </solution>

    Take care NOT to terminate directory paths with a backslash as this will cause file reference tags to fail.

  • Barry Gervin July 4, 2006 4:48 PM

    Hi Barry,

    I really appreciate this article. There is hardly any information out there, about how VS 2003 resolves it's assembly references.

    Also, I have a strange problem -

    VS 2003 will not pick the assembly I direct it to in my HintPath, even if there is no ReferencePath set. It finds an assembly with the same name somewhere in my system! And there is only one reference to that assembly in the entire solution (so the possibility of picking the assembly from the ReferencePath automatically added by VS does not apply here ?)

    Perhaps, it has something to do with the GAC, but I would really really appreciate any insights you can provide.

    Here's are my posts about this issue on MSDN forums -

    (Posts by Adrigo Gallus)
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=525395&SiteID=1
    http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=527298&SiteID=1&mode=1

    I will keep checking this page.

    Thanks,
    Adrigo

New Comments to this post are disabled