Installing shared assemblies into the GAC for development and build

Question

I've read a few posts around here about the GAC and why you should never deploy applications by installing shared assemblies into the GAC. This i can see sense in as it should make updating applications on client machines easier.

However, there are two areas where i could see the GAC being useful is for during development and on a build server.

For instance, if you use the Microsoft Application Blocks you could well install them into the GAC and reference them there. That makes sense as it is easier to do this than have and absolute reference to a path with might be different on each developers machine. It is also better than having a shared network drive with all your shared components - been there done that.

You would then presumably do the same for your build server. However the only problem i see with this is that you have an app that uses version 2.0 of the application blocks. Later on you upgrade this to use version 3.1. At some point you might need to re-create your earlier version of that application to test a bug a customer has found but when you recreate the build it will pick up version 3.1 of the application block rather than 2.0 which it was originally built against. Is this true, or will the old project file still reference the older version of the dll so long as it is in the GAC?

What are your thoughts/opinions on this particular point?

I would like to be able to distribute all version of shared components (we either download or build) to all developers as MSI's which install into the GAC and are 'XCOPY' deployed as part of an application installer to customer machines. Is this the best way to do this.

Answer 1

The old application will pick the older version of the assembly from GAC provided that you don't rebuild the old application with the newer assembly. Every assembly keeps this information in it's own manifest that which assemblies does it refer to. If you open up an assembly using ILDasm tool, you can inspect the Assembly's manifest in detail which keeps the information of all the referred assemblies.

Answer 2

What are your thoughts/opinions on this particular point?

I always keep primary binaries in the Resource/Library folder of the .NET software project. Obviously this folder is versioned. Storage is cheap these days anyway, so it does not make a big difference.

This serves a few purposes:

• Projects are atomic and they do not depend on having a specific version of some library in GAC. So it is easy to reproduce some previous revision by simply checking it out. And everything will work.
• It just requires a clean development machine (with all the .NET service packs and primary SDKs installed, of course), in order to start check out a project, run full integration build and start working.

When there are more than 10 different projects to manage, this starts making some difference.