How should I reference my Assembly in my Project when the Assembly will be registered to the GAC

Question

I have built a .NET Assembly and have registered it to the GAC I find it in "C:\Windows\Microsoft.NET\assembly\GAC_MSIL" after it is installed with the MSI installer.

Now on my development computer when I build a project which uses this Assembly what reference should I be using. I know if the Assembly is registered then it takes precedence so on my development machine it is not registered. I use a simple path to the the BIN folder of the Assemblies project.

But my question is: can this then cause problems or even slow things down later when my main project (that references this .dll) is deployed and of course the path I was using is no longer valid?

I know that the Assembly is still found in the GAC, but Im interested to know if this can lead to problems.

Answer 1

The GAC is a deployment detail. It nice for a company like Microsoft so they can reliably deploy security and maintenance updates for .NET Framework assemblies and be sure that there are no stray copies of the assemblies in a folder somewhere that they can never find back and update.

Using the GAC yourself on the dev machine often leads to tears. It is just way too easy to make an update to your source code and completely forget to change the [AssemblyVersion] or to re-register the updated assembly. Which causes your program to load the stale DLL that doesn't have the changes, you'll lose an hour of your life trying to figure out why the changes don't appear to work.

The reference assemblies of a project should never be an assembly in the GAC, always a copy that you keep around somewhere. Either generated by building a project (the very common case) or checked-in to source control. Just like the .NET reference assemblies, its copies are located in c:\program files\reference assemblies.

Even on the user's machine you should think twice about using the GAC. DLL Hell is always an issue that should worry programmers. If you have two programs that both use a single DLL in the GAC then it is pretty easy to deploy a bug fix for the DLL that fixes an issue in one program but plays havoc on the other program. A problem you don't have when you use local deployment, putting a copy of the DLL into the same directory as the EXE.

Maybe you have the same update concerns as Microsoft has, the GAC certainly is useful to reliably find a DLL back. That however isn't very common. Local deployment should almost always be your first choice.

Answer 2

Whatever you want - it depends if you want to debug your assembly or not. If you do not need to debug your assembly, than load it from the GAC (it is after all the first place that is searched when an assembly should be loaded).

IMO it should not be a problem and it should not lead to any performance issues. The assembly location determination is a process that IMO is not so costly, to be considered.

The combination you are using is actually often the case when developing a software using a third party library, for example Microsoft Patterns and Practices Library is installed in the GAC on the development machine and is referenced and loaded from the GAC, but in the LIVE environment the Lib-Assembly is delivered in the application bin-directory. At my work this is the preferred way to develop and deploy MVC applications, because this simplifies the deployment process a lot. You can have a look at this SO answer and this MSDN article - How the Runtime Locates Assemblies.