0

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.

Chris Ballard
  • 3,771
  • 4
  • 28
  • 40
darbid
  • 2,545
  • 23
  • 55

2 Answers2

3

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.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • Nice advice and explanation. – keenthinker Mar 15 '14 at 12:00
  • Yes it is Pasty. Thank you. And I understand it I think. So Hans if I understand you correctly if you had 1 Assembly and 4 projects that used it, you would reference this assembly in all 4 projects and in Visual Studio use "Copy Local" (I think it is called) and then when you deploy you would deploy this copy of the .dll along with each project? – darbid Mar 15 '14 at 12:09
  • Yes, that's the way it works by default and doesn't require anything special. After the solution is built, you'll find everything you need to deploy in the main project's bin\Release directory. – Hans Passant Mar 15 '14 at 12:20
  • At the risk of asking another question if I hope, (HOPE) say in 6 months time to try and make a COM .dll which will allow an Office Developer VBA to call some of my .NET Assembly, then my .NET assembly will then have to be registered in the GAC right? If you prefer I start a new question let me know. – darbid Mar 15 '14 at 12:54
  • COM is different, it has DLL Hell problems in spades because registration is machine-global. And the CLR can't find dependent assemblies. You *do* want to use the GAC for a COM server and religiously change [Guid] and [AssemblyVersion]. Pretty unwise to not mention this in your question btw. – Hans Passant Mar 15 '14 at 12:59
  • Sorry for not mentioning this. I was not expecting such a clear understandable answer nor the type of answer. So right now I could take the easy way and use my assembly locally for each solution and if I one day want to expose it to COM then have difficulty with registration etc. Or I could keep my DLL in the GAC and learn/sort out my issues and I will be better prepared if I ever write the COM .dll to access this .NET assembly. – darbid Mar 15 '14 at 13:31
1

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.

Community
  • 1
  • 1
keenthinker
  • 7,645
  • 2
  • 35
  • 45