Last post Jan 06, 2011 10:01 PM by istever
Jan 01, 2011 11:30 AM|firingnow|LINK
I know that GAC is a repository of assemblies. Actually a dll can be placed in a normal folder and can be shared. So what is the need to putting the assemblies in GAC and using it..
Jan 01, 2011 01:33 PM|shabirhakim1|LINK
In simple words i will explain Purpose of GAC is that all of its dlls/assemblies are shared among different application.so it serves as global repository while having normal folder dll can be for single application like we use bin directory.
Assemblies deployed to the GAC have full trust, while the assemblies deployed to the bin folder runs with the trust level specified for the web application (standard or custom CAS policy).
Assemblies deployed to the GAC available to all of the web applications, while while the assemblies deployed to the bin folder are local to the given web application.
Jan 02, 2011 11:32 AM|shaalim|LINK
Very Simple question, I would try to give very simple answer...
- We place assembly in GAC if application needs to be shared among many applications like Crystal Reports Assembly.
- If you need some special secutiry for the assembly like only an administrator can remove assembly.
Also note down versioning is possible for assemblies stored in GAC.
If you find Information useful then mark as Answer.
Jan 02, 2011 03:01 PM|aspnet2sams|LINK
Extending the query: Do the GAC assemblies compulsory to have strong names or it can be placed as a dll file? I mean can a dll in assembly is harmful in terms of being exposed by reflection or other techniques?
Jan 03, 2011 12:27 AM|firingnow|LINK
Thanks 4 ur reply, but is it not possible to do these things by keeping the assemblies in a normal folder instead of a GAC folder?
Jan 03, 2011 12:38 AM|shabirhakim1|LINK
of course you can do but once it comes to security Assemblies deployed to the GAC have full trustSince you will have multiple applications using the same DLL, the GAC would be the right place for it.if you updated your DLL, you would want it to available
to all the apps that use it. If this is so, now you have to go searching
for all instance of this DLL on the machine, and find all of your apps, and
update each one of these - instead of just updating it in the GAC and being
done with it.
It really depends on the situation you are in. LIKE sometimes you want to use webpart or smartpart,you need to deploy it in GAC because such controls are used by multiple application because of reusability.
Simple I can imagine upto sky because i can see it, not beyond sky. because, i have not seen it. i mean once you will met with situation,you will understand why to use GAC and Not bin or vice versa
Jan 03, 2011 10:15 AM|Deleo|LINK
Hey, let me share my thoughts about GAC.
You can of course emulate the GAC by using your own logic and folders, but the question then is Why reinvent the wheel?
If you are the only one administrating the server and maintaining the code, then knock yourself out. If however there are other people responsible for your code and server environment after release, then you should stick to standards and make it as easy
as possible for maintenance. Imagine an administrator having to deal with hundreds of different application doing its own things with dll and references, it would be crazy.... Here comes the GAC into play, by easy sharing trusted assemblies amongts applications.
The administrator has full control over code security inside his servers by setting priviliges on assemblies.
Updating your application would also be a walk in the park if its assemblies are shared amongst others, by using GAC and refering to the correct version in the manifest. :)
Jan 06, 2011 10:01 PM|istever|LINK
Do you remember those blue screen of deaths....thats where the GAC plays an important role. Think of the GAC as a temporary holder for those multiple dll assemblies. What i mean is if you were to install a program....and then a few days later update it
with the dll file not being updated...bam blue screen of death. So in essence, the GAC can hold multiple versions of the dll for that specific program.