Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 645
  • Last Modified:

GAC, Windows Assembly

Can someone clear up something for me.  What is the difference between the GAC and the c:\windows\assembly folder?   I thought I read they were one in the same.  

However, I've being trying to add a DLL to the GAC.  I created an MSI setup for my DLL.  This DLL in turn has a dependency on a third party DLL.  When I run the install, I see the  third party DLL in c:\windows\assembly.  However I do not see my DLL.   So, I tried using the GACUTIL from the command line to install my DLL to the GAC.  That worked.   I can list back my GAC entry using  GACUTIL.  I can also list the third party DLL using GACUTIL.   However I still do not see my DLL in  c:\windows\assembly.

Can anyone explain this?
0
HLRosenberger
Asked:
HLRosenberger
  • 4
  • 3
  • 2
3 Solutions
 
Grant SpiteriSenior consultantCommented:
Are you running .net 4.0 framework if so GAC location has changed: %windir%\Microsoft.NET\assembly\
0
 
HLRosenbergerAuthor Commented:
Ah, thanks!   that explains my DLL.  now I see it!   Why do I not see the third party DLL in the %windir%\Microsoft.NET\assembly\ path?  Instead I see it in c:\windows\assembly.  

However, GACUTIL lisst both DLL.   Why?          
0
 
Grant SpiteriSenior consultantCommented:
At a guess i would say the third party assembly was not compiled in a 4.0 solution
0
Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

 
HLRosenbergerAuthor Commented:
that was my guess.   So, this third party provides DLL's for .NET 1.1, 2.0, 3.5 and 4.0.   If I'm running 4.0, and my DLL uses the 4.0 version of the third party DLL, why would it end up in the older GAC location?  is there a way to force it into one location or the other?

And this means GACUTIL pull from both locations, since I can list my DLL and the third party DLL.  
0
 
Jacques Bourgeois (James Burger)PresidentCommented:
is there a way to force it into one location or the other?

When anybody could "force" things like that, such as in the older System folder, it became a mess.

They solved that problem in .NET with the GAC and Gacutil. Let the GAC manage itself. The framework will find your dll that way. If everybody could start fooling around by "forcing" things, we would end up with the same old mess.

If you want to have control over the location of a dll, put it in the application folder or use a CodeBase in the assembly configuration file to specify where it is. If you want it in the GAC, let the GAC work for you.
0
 
HLRosenbergerAuthor Commented:
Sorry. I do not want to force it.   I'm trying to understand why the third party DLL I am using is in one GAC and my DLL is in the other.   I'm using .NET 4.0.  If the third party DLL is meant to be used with 4.0, why is it in the 2.0 GAC?  That's what I'm trying to figure out.
0
 
Jacques Bourgeois (James Burger)PresidentCommented:
OK, clearer now.

Try to find a computer on which you installed only the framework 4.0, with nothing before, and it might help you to understand. Nothing of what I will tell you is official, just my own opinion from observation.

%windir%\Microsoft.NET\assembly\ contains only dlls that are part of the framework, all the namespaces that are System..... nothing else

c:\windows\assembly contains everything else: Office interops, SQL Server management, third parties components, dlls from older versions of the framework that Microsoft neede to keep there for compatibility reasons.

Prior to the 4.0 framework, the framework was mixed in with everything else. It was hard to differentiate between what was the framework and what was accessory or installed by some other application.

My suspicion is that they wanted to make that separation cleared. The GAC is thus now made of 2 parts: the framework part, and the "everything else" part. They may have some internal reasons to do so, such as easier deployment of service packs.

It might also be easier on the security front, because the directories being different, they might be able to apply different permissions (this would have to be proven). Traditionnally, the user needed to be administrator to install something in the GAC, but was able to install the framework in the GAC on a user account. Since security is usually managed at the directory level, having c:\windows\assembly behaving in 2 different ways depending on what was installed in it was possibly a headache. Having the GAC in directories might make things easier. Just guessing here.

But it is clear that they separated the framework from everything else in 4.0.

The third party is not part of the framework, so in installs in the non-framework part of the GAC.

That is how I see things. Now, if somebody form the framework development team is seeing this, maybe they can give the real reason behing all of that.

0
 
HLRosenbergerAuthor Commented:
Thanks so much. I appreciate that you took the time to explain.  One last question:  My DLL is not part of the framewok, but it was installed in the %windir%\Microsoft.NET\assembly.   Thoughts?
0
 
Jacques Bourgeois (James Burger)PresidentCommented:
You should ask the gods at Microsoft. They often have strange ways, but usually good answers to explain their ways :-)
0

Featured Post

Become an Android App Developer

Ready to kick start your career in 2018? Learn how to build an Android app in January’s Course of the Month and open the door to new opportunities.

  • 4
  • 3
  • 2
Tackle projects and never again get stuck behind a technical roadblock.
Join Now