What is the best way to handle references in a .NET application

Question

Recently at work we ran into a problem where we tagged/branched a project and had some compiling issues because of dll/project references that was pointing to the old folder structure.

We created an 'external bin' folder for each of the projects and copied the referenced dll's to these folders. Is this the best way or is there a specific industry standard to handle this?

Answer 1

I would say that nuget is the best way to handle dependencies.

nuget can manage versions AND automatically download the dependencies from your local nuget server.

It's quite easy to create/configure a local server. Simply create a new empty ASP.NET project and install the nuget-server nuget package (using nuget ;).

That also means that you wont have to check in all dependencies and/or manage their versions using TFS.

Answer 2

This depends on how your solution is structured and what your version control software capabilities are. Previously, we used to keep an unbuilt/skipped project in our solutions that held documentation and a folder specifically for any third party referenced libraries. Since it was part of the solution, the path to these files could be referenced using the relative path. After we moved to TFS 2010, got rid of this project and simply added a "Support" directory in that solution's folder in the team project parallel to our main branches. In either case, the source control version of the library ends up being in the same place relatively regardless of how the developers have their machines configured.

Answer 3

Its not really - Microsoft says the best way to handle references is to build your project in one huge solution. Yes, I know, they really do mean it too.

The patterns and practices team have put their best practices together with regard to TFS, but it applies to general builds. There are 3 types of solution setup, the "1 big solution", a partitioned approach which is a lot like how most people used to manage builds by building in turn and copying artifacts to a common directory (which si not helped by .NET not having a server-wide 'include' or 'library' path to reference), and a Multiple Solution setup which is a more complex version of the Partitioned one.

They say

In general you should:

    Use a single solution strategy unless the resulting solution is too large to load into Visual Studio.
    Use multiple solutions to create specific views on sub-systems of your application.
    Use multiple solutions to reduce the time it takes to load a solution and to reduce build time for developers.

For TFS they recommend branching any external projects inside your project, rather than relying on the workspace mapping that is more akin to subversion's externals. Personally, I think their advice there is not best practice, but I suppose they are trying to minimise any build issues you'll get when using references.

I have had issues with .NET builds that try to shortcut the system by building only what's needed, a nightly build that does everything, and copies every new assembly to a directory was the best way for everyone to keep in sync - especially the testers. Note this really only applies to .NET apps, C++ ones tend to still work because they don't have versioned assemblies or similar aspects that can cause problems with calling components. This approach works well, but you can't always assume that partial builds are ok, vaping the whole thing and rebuild is safest.

Answer 4

When using subversion for version control, you can utilize the "externals" property for this purpose. This allows you to keep a local copy of a shared DLL in a relative path nearby your current project. That makes it easy to reference that DLL by a relative file path which does not change, even when you change the main directory of your project to a different folder. Externals let you also define which specfic version or revision to include.