Updating GAC dlls

2018-06-24 02:05:20

I got a DLL registered in the GAC which has a bug in it (v4.2.0).

I've therefore fixed that bug, updated the file version only (v4.2.1) (keeping the assembly version, v4.2.0) and built a new MSI package.

The problem is that the DLL is not installed in the GAC. I verified this by right-clicking on the DLL in C:WindowsMicrosoft.NETassemblyGAC_MSILMyDLLv4.0_4.2.0.0__2269313d92725976 and checked the file version, which is still v4.2.0 There are also no other folders created under C:WindowsMicrosoft.NETassemblyGAC_MSILMyDLL .

But! If I uninstall the first version and then install the new DLL it get's installed OK in the GAC.

Am I approaching this the wrong way? Our applications are set to use specific versions, so just creating assembly version v4.3.0 and install it in the GAC wont work.

Update

I've found the article about publisher policies ( http://support.microsoft.com/kb/891030) and are attempting that instead. I've generated the policy assembly. But Visual Studio crashes when I try to add it to the setup project =(

I've also tried to add it as a content file to the primary project (and then add content files to GAC). But then it complains on the assembly not being signed.

So I'm still stuck.

Updating the [AssemblyFileVersion] for a bug fix is usually the right approach, although it gets iffy if you do so for an assembly in the GAC. You run the risk of breaking another app that also uses the assembly and unintentionally depends on the buggy behavior to function correctly. An unintentional mistake like renaming a public method is of course always a good way to break an app, the road to DLL Hell is paved with many good intentions that turned out bad.

The GAC however only pays attention to [AssemblyVersion] and ignores the file version. To get the updated assembly to replace the existing one you do have to remove the old one first. This is intentional, preventing accidental replacement.

A <bindingRedirect> in the .config file of the app you want to repair will be a lot easier to get going than a publisher policy.

I believe this has to do with what parameters of a .NET assembly the GAC uses to give it a unique identifier. If the assembly version is one of those uniqueness parameters, but file version is not, that may explain your symptoms. Specifically this pertains to the GACs need for a strong named assembly

This link says as much

http://msdn.microsoft.com/en-us/library/wd40t7ad.aspx

链接地址: http://www.djcxy.com/p/67488.html

上一篇: 在路由规范中指定默认格式

下一篇: 更新GAC dll