Menu
I have a data access layer (DAL) that is written in ASP.NET 3.5 and uses the Microsoft patterns & practices libraries (hereafter referred to as P&P) in order to accomplish its data access. I installed P&P and it resides in my GAC, so, logically, my DAL references it in the GAC. Therefore, the P&P libraries are never pulled down to the bin folder of my DAL.
I use this DAL project in at least five (more than that even, but I'm too lazy to try to count them all) different websites. And this has all worked just fine for me because I'm the only developer who works on these websites.
But, now I have other developers who are going to work on some of these websites.
The problem: if a developer pulls the DAL project down from our code repository, it won't build for them if they don't have the P&P libraries installed.
My question: should I expect the developers to install the P&P libraries, or should I just dump them in the bin folder and be done with it?
I realize that dumping them into the bin folder is probably the easiest way to deal with the problem, but I've never been a big fan of the bin folder if I can reference them in the GAC instead.
833
Why would I avoid the GAC? The GAC should contain “global” shared assemblies only, so there are many instances when you would NOT install an assembly in the GAC: The assembly is private to your application and not to be shared with other applications.
The best answer was that "The GAC is only useful if you register libraries which you're going to reuse." In other words, don't use it if you are not going to share libraries between different applications. Save this answer.
There are two ways to remove an assembly from the global assembly cache (GAC): By using the Global Assembly Cache tool (Gacutil.exe). You can use this option to uninstall assemblies that you've placed in the GAC during development and testing. By using Windows Installer.
Basically GAC stores assemblies specifically to be shared by many application on computer. The Global Assembly Cache (GAC) is a folder in Windows directory to store the . NET assemblies that are specifically designated to be shared by all applications executed on a system.
This is largely stylistic preference for your particular workgroup. I tend to favor packaging websites the same way I package client applications: with all required non-.NET-framework binary files in the bin folder, working with the assumption that any machine that they are copied to/installed to will not have anything in the GAC. My team at work keeps our third-party assemblies checked into source control as binary files and tagged as reference dependencies so that everyone works on the same page with the same binaries and we never have to worry about installation differences between developers' machines.
The GAC may be a convenient space-saving mechanism, but I prefer the consistency between developer environments provided by "inlining" the files.
81
Having worked on projects with GAC dependancies in the past, Its always been confusing and hard to configure projects correctly, causing all kinds of delays just getting started. It can become a bigger problem as you develop new versions of the DAL. This may have worked well when you where solo but I would really consider the bin dump now that you have a larger team.
31
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
