Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

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?

share|improve this question

4 Answers 4

up vote 18 down vote accepted

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.

share|improve this answer
1  
I find that most companies fail to utilize this well. In fact, I have yet to see a build server properly configured to gain the benefits of this, so +1 for something I'd like to see everywhere. –  deltree Sep 17 '12 at 11:58
    
I planned to ask a question if nuget could not be scripted (or something) to keep packages unversioned and download the dependencies automatically… And the first search result tells me that nuget supports this out of the box! Thanks! –  Mormegil Feb 8 '13 at 8:15

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.

share|improve this answer

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.

share|improve this answer

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.