Issue: Comparing the assembly name resulted in the mismatch: Revision Number

Question

_{Tuesday, November 23, 2010 8:41 PM}

 

Hi,

I have a VB.net 2005 project MyProject.exe which is referring to a strong named dll ReferenceDll1.dll in its references. The ReferenceDll1.dll is referred as Specific Version=False. The version on the strong named reference ReferenceDll1.dll was 1.0.1.2 when I compiled my project. Few days later, I got updated ReferenceDll1.dll as 1.0.1.3. Replacing this dll in the install directory fires following exception.

System.IO.FileLoadException: Could not load file or assembly 'ReferenceDll1, Version=1.0.1.2, Culture=neutral, PublicKeyToken=0242eaa067ef8af5' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'ReferenceDll1, Version=1.0.1.2, Culture=neutral, PublicKeyToken=0242eaa067ef8af5'
   at WindowsApplication3.Form1.Form1_Load(Object sender, EventArgs e)
   at System.EventHandler.Invoke(Object sender, EventArgs e)
   at System.Windows.Forms.Form.OnLoad(EventArgs e)
.
.
WRN: Comparing the assembly name resulted in the mismatch: Revision Number
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

I do not want to compile the MyProject.exe when I get updated versions of ReferenceDll1.dll. Is there any way to get MyProject.exe running with updated version of ReferenceDll1.dll without compiling MyProject.exe? Also, I do not want to keep the old ReferenceDll1.dlls (like 1.0.1.2) into GAC. Please let me know if I can refer the strong named dll for above scenario? Is it possible to refer this strong named reference without referring to specific version of it?

Thanks,
Gangadhar

All replies (2)

_{Wednesday, November 24, 2010 2:21 AM ✅Answered | 1 vote}

Gangadhar,

The Specific Version property is only a build-time directive. See this article for more information.

http://blogs.msdn.com/b/irenak/archive/2005/12/13/503105.aspx

I believe what you will need to do is to create either an application policy or a publisher policy that you install when you update the DLL.  The following articles describe how to do this.  The first article explains the reasons for why the DLL versions are locked at build-time.

Simplifying Deployment and Solving DLL ____ with the .NET Framework (http://msdn.microsoft.com/en-us/library/ms973843.aspx)

How to: Create a Publisher Policy (http://msdn.microsoft.com/en-us/library/dz32563a%28v=VS.90%29.aspx)

I hope this helps.

---

_{Thursday, November 25, 2010 12:04 AM | 1 vote}

Hello TnTinMN,

Yes, I got what I wanted from these articles. I will need to create application policy for the scenarios that I mentioned. Thanks a lot for your help and directing me to right links.

Thanks,
Gangadhar