How should I reference assemblies from another solution?

Question

I have two scenarios:

There is a Framework project for the company, and for all projects we are going to use this framework.
There is a custom Framework project which is specific for a client and only some people in the company will ever need to use this DLL.

Both frameworks are stored in separated solutions on TFS.

How should one use the references for other projects? Should I put the both assemblies on GAC or something? Should I copy the output assembly manually? What is recommended, why and how I use it?

While this may be not be valuable to your situation, if you were using subversion, svn:externals would have been a rather simple solution to this situation. — Candide, Mar 05 '12 at 14:26

jgauffin · Accepted Answer · 2012-03-05T14:58:46.940

Custom framework

Copy the output assembly manually for the custom project unless you can include it's source directly in the solution.

Shared Framework

I would use nuget instead of GAC any time since you get rid of any versioning problems or having to create a separate installation package for framework (since you GAC)

It's easy to create a private nuget server. Simply create a new MVC3 project and install a the nuget server package: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

score 5 · Answer 2 · answered Mar 05 '12 at 14:19

5

Add the referenced assembly to a library folder in the other projects and manually update it. Consider using your own NuGet feed if updated frequently.

answered Mar 05 '12 at 14:19

Chriseyre2000

2,053
1
15
28

score 4 · Answer 3 · answered Mar 05 '12 at 20:58

Sounds to me a classic project reference vs binary reference decision making. Leave the GAC out of this.

In topologies which resembles your requirement we use something like this:

|___$/3rdParty/
|     |__BaseFramework.dll
|     |__CustomFramework.dll
|     |__log4net.dll
|     |__WPFToolkit.dll
|
|___$/Sources/ProjectName/NormalProject.sln
|                         |
|                         |__[Binary Reference] "../../3rdParty/BaseFramework.dll"
|                         |__[Project Reference]
|                         |__[Project Reference]
|
|___$/Sources/Common/BaseFramework.sln
|                    |
|                    |__[Project Reference]
|                    |__[Project Reference]
|                    |__[Project Reference]
|                    |__[Project Reference]
|
|___$/Sources/Custom/Acme/AcmeProject.sln
|                         |
|                         |__[Binary Reference] "../../../3rd-party/CustomFramework.dll"
|                         |__[Project Reference]
|                         |__[Project Reference]
|
|___$/Sources/Custom/CustomFramework.sln
                    |
                    |__[Project Reference]
                    |__[Project Reference]
                    |__[Project Reference]
                    |__[Project Reference]

Massimiliano Peluso · Answer 4 · 2012-03-05T14:26:07.393

You should share assemblies by installing them into the global assembly cache only when you need to. As a general guideline, keep assembly dependencies private, and locate assemblies in the application directory unless sharing an assembly is explicitly required. In addition, it is not necessary to install assemblies into the global assembly cache to make them accessible to COM interop or unmanaged code

I would put the first framework ddl's into the GAC because of the above.

I would put the second framework into a designed folder under your TFS called by instance "Library" where you will add a reference from (All your team must have the same folder structure to avoid missing references)

score 1 · Answer 5 · answered Mar 05 '12 at 14:26

So #2 the custom Framework project is the same thing as #1, but customized for a particular client?

Would it make sense to make the custom Framework source code a branch of the normal Framework source code, instead of keeping it as an actual separate solution? I suppose that it would depend on how extensive the differences are.

As I see it, the advantage of making it a branch is that you should be able to more easily merge changes between the two branches. Imagine that a bug fix or a new feature is made in #1 and also needs to be applied to #2; TFS should be able to make this easier, provided that TFS is aware that #2 is just a branch of #1.

Anyway, to get to the point of your question, my thought then is that your other projects should reference the output assemblies from these projects.

I would copy the Framework assemblies into a folder under the solution folder of your other projects. I generally call mine "Dependencies", but it really doesn't matter. Have your projects add a reference to those assembly files. I am assuming that your custom Framework assemblies will have the same name as the normal Framework assemblies, so you can hopefully easily swap those files out as needed (or create separate branches of your projects that use the custom Framework).

I would discourage putting the assemblies into the GAC, because it is easy to trip yourself up during development if you forget to uninstall an older version of the assembly from the GAC.

How should I reference assemblies from another solution?

5 Answers5