Help understanding the GAC_MSIL directory

Question

User-1670588033 posted

hi there,

I have a Class Library Project that makes a reference to a dll

when I right click the reference I see this path for the DLL:

C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Practices.EnterpriseLibrary.Logging\2.0.0.0__bd5a587c51257568\Microsoft.Practices.EnterpriseLibrary.Logging.dll

Now, If I creeate a new project and open the Add reference wizard, this dll doesn't appear on the .NET tab.

If I copy the path:

C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Practices.EnterpriseLibrary.Logging\2.0.0.0__bd5a587c51257568\ 

 above in the execute box,  I can manually copy the DLL to some other folder and browse to it.

That works but I feel I'm doing something wrong and I'm not getting some concept behind that...

Please help me understand the C:\WINDOWS\assembly\GAC_MSIL directory.

It's a strange directory because it doesn't appear on the windows explorer if I try to browse to it....

Thanks

 

Answer 1

User1998656370 posted

I see know one else has replied to this, so I thought i'd help push along an answer for you, with what I know about the GAC - This may not be EXACTLY how it all works, but it is MY UNDERSTANDING of it - maybe someone with more expertise may be able to elaborate on it also.

The GAC (Global Assembly Cache) is a central reposiroty for assemblies to reside, ready for the CLR (Common Language Runtime) to convert the code into the native code for the host operating system to execute. As .NET is not specific to a "language", i.e. C#, VB, j# etc can be used to write .NET apps, the CLR interprets the real code which is in the Microsoft Intermediary Language (MSIL). In effect, this means we write it in c#, it is compiled into MSIL, and then executed by the CLR Just in Time (JIT) when it runs. Thus dlls in this MSIL format are in the .NET GAC. The benefit of this is that independant languages can access the dlls, it doesn't matter if it's c#, vb or j# that we are using. The GAC also allows us to have one view of a file, so as far as we are concerned, it is Microsoft.Practice.EnterpriseLibrary.Logging.dll, but in the GAC we may have several different versions of this. When using the dll, we can specify the version we need, and the GAC gives us the right version that we need. Another benefit is that by installing the dll into the GAC, we do not have to distribute it alongside the EXE everytime, as it is found inside the Shared GAC - imagine if everytime you built a .NET app, you had to distribute all the System.bla.bla.bla.dll files with the exe file!

So in essence, it's a shared location for dlls to reside, so we don't have to distribute them everytime. It also allows us to manage versions of them. It's called the GAC_MSIL because it's the global assembly cache of microsoft intermediate language format dlls. The latter part of the folder structure is the version number.

The reason why you don't see the folder, is that the GAC is acting as an abstracted layer for us, hiding the complexities for 99% of .NET users, and allowing an easy entry point for registering .NET assemblies / dlls.

If anyone else has anything to add, then please do so - and if i'm wrong about anything, please correct politely.

James.

Answer 2

User-1670588033 posted

Good posting Wyrarch, you helped me to have a better understanding of the GAC.

I still have this doubt, though:

Even though the GAC " is a central reposiroty for assemblies to reside, ready for the CLR (Common Language Runtime) to convert the code into the native code for the host operating system to execute " like you said, I still have to add references to those assemblies in my projects, right?

When I open the Add references wizard, there are 5 tabs: .NET, COM, Projects, Browse and Recent 

I thought that every asembly that is on the GAC was going to appear in the .NET tab. But that is not true.

I have an assembly that is on this path:

C:\WINDOWS\assembly\GAC_MSIL\Microsoft.Practices.EnterpriseLibrary.Logging\2.0.0.0__bd5a587c51257568\Microsoft.Practices.EnterpriseLibrary.Logging.dll

However I can't see it on the .NET tab nor browse to it using the Browse tab.

Maybe I have to run a command to register it in the GAC and so it will appear on my .NET tab?

Thanks

 

Answer 3

User1998656370 posted

Sorry, yes, I should have added that, and actually answered the question!

 

To me it does sound like it hasn't been registered correctly in the GAC, and therefore, that is why you are manually having to add it yourself.

I have had the exact opposite problem before, where I have had dlls in the GAC, but i've wanted them as dlls to distribute, so at times it can be quite frustrating!

You chould be able to register the file if you place it in a location known to you, and try the following:

c:\>gactutil -i c:\foldername\assemblyname.dll

Thanks,

James.

Answer 4

User-1670588033 posted

I ran this command:

C:\>gacutil -i D:\APPLICATION\DLLs\Microsoft.Practices.EnterpriseLibrary.Excepti
onHandling\2.0.0.0__bd5a587c51257568\Microsoft.Practices.EnterpriseLibrary.Excep
tionHandling.dll
Microsoft (R) .NET Global Assembly Cache Utility.  Version 3.5.21022.8
Copyright (c) Microsoft Corporation.  All rights reserved.

And got this outout: 

Assembly successfully added to the cache

But Microsoft.Practices.EnterpriseLibrary.ExceptionHandling still doesn't appear on my .NET tab in the Add reference wizard.

I restarted Visual Studio but I still can't see that assemblie... Maybe I'm missing something

Thank you

Answer 5

User1998656370 posted

Without sounding too I.T, have you tried rebooting? No seriously, i'm a bit at a loss now, i'd try a reboot and see what happens!

Answer 6

User-1670588033 posted

Hi there!

I figured that if I copy the DLL to this folder:

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\

I can see the component on the Add References wizard.

But this is something that doesn't make any sense to me because:

What if the dll I copy there isn't the same I registered on the GAC?

Wouldn't that be a mess?

 Thanks 

 

 

Answer 7

User-1156191886 posted

I've hit similar problem and after some reaserch I've found, that you could add key with name of Enterprise Library folder in regestry under this key HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders and Visual Studio picks up assemlies from EntLib.

In my case it was: C:\Program Files\Microsoft Enterprise Library January 2006\bin. Yes, we are using EntLib 2.0.:) It's just a local caprice of the univers.:)

 So, by adding appropriate key in mentioned above location you could point VS to pick up EntLids from anywhere you want.  I'm still having problems, though, to understand why installation of Enterprise Library didn't take care about such an obvious thing, as making sure, that VS will pick up correct libs for referencing.