Add-in fails to register during upgrade install

Add-in Express™ Support Service
That's what is more important than anything else

Add-in fails to register during upgrade install
 
Chris McA


Guest


I have an issue where my add-in is failing to register correctly if I do an upgrade installation. So, if I install a build, then make some changes and build a new installer, when that installer is run then most times (not always, but nearly always), the add-in will not have been registered correctly as reported in adxregistrator.log;

Application Domain: C:\Program Files (x86)\<snip>
Assembly Codebase: file:///C:/Windows/Microsoft.NET/Framework/v4.0.30319/mscorlib.dll
Assembly Full Name: mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
Assembly Version: 4.0.0.0

Exception Source: mscorlib
Exception Type: System.IO.FileLoadException
Exception Message: Could not load file or assembly '<my assembly>, Version=<snip>, Culture=neutral, PublicKeyToken=<snip>' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Exception Target Site: GetExportedTypes


The assembly that is being reported as mismatching on the manifest definition is not my actual add-in DLL, but one of its dependencies.

It can always be remedied by doing a "Repair" install using the same MSI, so it doesn't seem like there's a problem with what is baked into the installer.

What might be causing this issue?

Thanks,
Chris
Posted 21 May, 2014 09:39:59 Top
Andrei Smolin


Add-in Express team


Posts: 18830
 Joined: 2006-05-11
Hello Chris,

This problem occurs if you deploy a set of files that differ from the one used when building the add-in.

Here's one of the way to achieve this. Consider an add-in containing two assemblies: Assembly1 Version 1 and Assembly2 Version 1. Now you build Assembly1 Version 2 and deploy Assembly1 Version 2 plus Assembly2 Version 1. When you register the add-in, you get the problem above. To avoid it, you need to rebuild both assemblies and deploy the new assembly versions.


Andrei Smolin
Add-in Express Team Leader
Posted 22 May, 2014 06:08:48 Top
Chris McA


Guest


Hmm, I almost always do a full clean and re-build when building my add-in - is there anything else that might cause this behaviour?

The only reason I'm curious is because I don't understand why doing a "Repair" install would resolve the situation you describe. I would think that if the MSI had mismatched assemblies in it, then it would just never install correctly?

What do you think?

Chris
Posted 22 May, 2014 14:52:22 Top
Andrei Smolin


Add-in Express team


Posts: 18830
 Joined: 2006-05-11
Chris,

Chris McA writes:
Hmm, I almost always do a full clean and re-build when building my add-in - is there anything else that might cause this behaviour?


Anything else? Only variations of the above. Say, you have Copy Local = true on some assembly reference; this compile okay but the installer produces this problem because the setup project gets that assembly from the output folder, not from the location specified by the reference.

Does the setup project produces warnings? Can it be that you deploy some assembly twice?

Chris McA writes:
The only reason I'm curious is because I don't understand why doing a "Repair" install would resolve the situation you describe.


I don't know.


Andrei Smolin
Add-in Express Team Leader
Posted 23 May, 2014 03:28:40 Top