How should I refer to 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 infrastructure.

• There is a special Framework project that is client-specific, and only some people in the company will ever need to use this DLL.

Both structures are stored in separate TFS solutions.

How to use links for other projects? Should I put both assemblies in the GAC or something else? Should I manually copy the output assembly? What is recommended, why and how do I use it?

Answer 1

User infrastructure

Copy the manual output assembly for the user project if you cannot include it directly in the solution.

General structure

I will use nuget instead of the GAC at any time, since you will get rid of any version problems or create a separate installation package for the framework (since you are a GAC)

Easy to create a private nuget server. Just create a new MVC3 project and install the nuget server package: http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds

Answer 2

Add the assembly reference to the library folder in other projects and manually update it. If possible, use your own NuGet feed if it is updated frequently.

Answer 3

A classic reference to a project sounds to me compared to a binary reference solution. Leave the GAC out of this.

In topologies that resemble 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]

Answer 4

You should share assemblies by installing them in the global assembly cache only when you need to. As a general guide, keep assemblies dependent in private and locate assemblies in the application directory unless assembly sharing is explicitly required. In addition, there is no need to install assemblies in the global assembly cache to make them available for COM interoperability or unmanaged code.

I would put the first ddl structure in the GAC because of the above.

I would put the second structure in the created folder under your TFS, called the Library instance, where you add a link (all your commands should have the same folder structure to avoid missing links)

Answer 5

So, a 2 user Framework project is the same as # 1, but configured for a specific client?

Would it be wise to make the source code of the custom Framework a branch of the source code of the Framework, instead of storing it as a separate separate solution? I believe this will depend on how vast the differences are.

As I see it, the advantage of creating a branch is that you should be able to more easily merge changes between the two branches. Imagine that a bug fix or new feature is made in # 1, and should also apply to # 2; TFS should be able to make this simpler, provided that TFS knows that # 2 is only branch # 1.

In any case, to get to the bottom of your question, I thought that your other projects should refer to the output builds from these projects.

I would copy the Framework assemblies into the folder under the solution folder of your other projects. I usually call my “Dependencies,” but it really doesn't matter. Let your projects add a link to these build files. I assume that your custom Framework assemblies will have the same name as regular Framework assemblies, so you can reliably easily change these files as needed (or create separate branches of your projects that use a custom Framework).

I would refuse to put assemblies in the GAC, because during development it is easy to disable yourself if you forget to remove the old version of the assembly from the GAC.