All geek questions in one place

Link to the global assembly cache

I have a project that should use NHibernate to communicate with my Oracle database.

Many projects in my workplace use NHibernate, so the NHibernate assembly has been placed in the global assembly cache, a tool that I don't quite understand. From my research, I have compiled the following:

  • The global assembly cache is the central repository for DLLs that many projects link to. This avoids the Hell DLL problem - when a new version of your DLL is released, you update it in the cache once, and all .NET projects that reference it will now use the new version.
  • You cannot add an assembly reference in the assembly cache. " Assemblies registered in the GAC will not appear in the [Add Link] list . However, you can force them to appear, distorting the registry.
  • You can easily add an assembly reference in the assembly cache. " just use the Add Link window to add a link to the assembly installed in the GAC ." (I tend to disbelieve this, since I do not see the GAC assembly in the add links window).
  • Several projects in my workplace have links to many assemblies in the GAC. These assemblies never appear in the Add Link menu, so I know that my predecessors did not use the reorganization technique. However, they explicitly come from the GAC — their file path is a subdirectory of C: \ Windows \ assembly.

Point two clearly contradicts the other three, but if it were just false, I would not have problems with links to libraries. This definitely reflects the reality that my GAC assemblies are nowhere to be found in the Add Links window.

I would like to know two things:

  • When will a developer ever want to use the GAC? What good is a library that cannot be referenced without registry tricks?
  • What steps did my predecessors take to link to libraries in the GAC without touching the registry?
+6
source share
5 answers

and all .NET projects that reference it will now use the new version.

No, this is called a DLL Hell. Applications refer to a specific version of the assembly. You can update the DLL and update the application that uses it. And do not crash the old application, which also uses this DLL, but has not been recompiled. You can do this with the GAC, as it can store multiple versions of the DLL. Or you can do it just as easily by saving the DLL in the same directory as the EXE application.

Assemblies in the GAC do not appear in the Add Link dialog box. Necessarily, you do not know what your user has saved in his GAC. Instead, you use the Browse tab on your development computer, so you'll be sure to use a specific DLL assembly.

GAC is important for companies that need to distribute security updates. Like Microsoft. This ensures that there are no unpacked copies of the DLL floating around. It is also important for the [ComVisible] collectors to solve the COM DLL Hell problem. What about that.

+5
source

The brute force method of adding a GAC ​​link to your project is to directly edit the project file. Unload the project and add a Reference under the same ItemGroup element as other links in your project, for example:

 <Reference Include="System.Management.Automation, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <SpecificVersion>False</SpecificVersion> </Reference>

You need to know that there is a difference between the location of the assembly nodes in the .NET tab of the Add Link dialog box and the runtime resolution of these assembly references in the GAC. The difference between adding a link through the .NET tab and the file browsing tab is that the link in the first case is not marked as "Copy local", and therefore it will be checked with the GAC at runtime. Microsoft usually places a copy of the referenced assemblies from the GAC in folders in the% programfiles% \ Reference Assemblies directory, but they are only used during development.

+3
source

1 .... you update it in the cache at a time, and all .NET projects that reference it will now use the new version.

Not really. You can control whether the application uses the new or old version. Great thing - both can be in the GAC at the same time.

  • What steps did my predecessors take to link to libraries in the GAC without touching the registry?

Just a) register it with GacUtil /i and b) Add Reference, browse to the original dll location. c) make sure the new ref has CopyLocal = false and StrongName = true

+1
source

It looks like my predecessors added a link to the assembly in the GAC:

  • Open a project that already contains an assembly link in the GAC.
  • Select the link and open the Properties panel.
  • Copy the full link path.
  • In the target project, select "Add Link" and select the "Overview" tab.
  • Paste the full path into the File Name text box and select OK.

However, looking at other answers, I doubt it is a good idea. It so happened that the GAC for development, testing and production environment are identical. If the GAC is not synchronized, the links probably will not remain valid.

+1
source

It may be too late to answer, but I found a very simple way to do this (without hacking).

  • Put your dll in the gac
  • GoTo Projects → Properties
  • Click Link Path and specify the path to the GAC
  • and build

Hope this helps

0
source

Source: https://habr.com/ru/post/899616/

More articles:


All Articles