gac

I have a .NET assembly that (for reasons outside my control) must be in the GAC. However, the same assembly is used by another program, which has a its own copy of an older version of the same assembly. It must use its own copy and not whatever is in the GAC. Proper versioning is probably more hassle than it's worth in this case, for reasons I won't go into. My questions is: is there anyway to tell .NET: just use THIS DLL, right here in this directory - ignore whatever you find in the GAC or anywhere else . Make sure the GAC Assembly and local Assembly have different version numbers (not a bad

Just looking for a short overview of GAC for a layman, not a link please. Tom Ritter Right, so basically it's a way to keep DLLs globally accessible without worrying about conflicts. No more DLL Hell. Each architecture and version gets it's own place to live. It also gets it own way to browse it in Explorer, so if you go to C:\Windows\assembly In windows explorer it lists all the DLLs. But if you fire up cmd , you can see how it's really structured: C:\Users\tritter>cd C:\Windows\assembly C:\Windows\assembly>dir Directory of C:\Windows\assembly 07/20/2009 02:18 PM <DIR> GAC 06/17/2009 04:22 PM

I've created a .NET assembly for COM interop and it is working well on my development machine. I'm currently trying to figure out how to deploy the DLL to a target machine using Visual Studio's "Setup Project." How can I use the VIsual Studio setup project to do the following things: Register the assembly (currently using regasm ). The assembly needs to be registered successfully and the type library (.tlb) needs to be registered successfully . This answer suggests scrapping regasm in favor of custom code. I this is a good idea? If so, how does this code get included in the setup project? This

And on top of that, are there cases where one has to use the global assembly cache or where one cannot use it? Loading assemblies from GAC mean less overhead and security that your application will always load correct version of .NET library You shouldn't ngen assemblies that are outside of GAC, because there will be almost no performance gain, in many cases even loss in performance. You're already using GAC, because all standard .NET assemblies are actually in GAC and ngened (during installation). Using GAC for your own libraries adds complexity into deployment, I would try to avoid it at all

When should you install into the GAC and when should you not? (I am referring, really, to installing on a client's machine when they have purchased our product(s)). I have an assembly that is only going to be used with my one application (GAC or no-GAC)? I have an assembly that all my applications share (GAC or no-GAC)? All my applications may use different versions of my assembly (GAC or no-GAC)? These are three scenarios... but I am sure there are more. I'm not necessarily looking an answer to only these three questions. Similar question: What are the advantages and disadvantages of using