Update add-in with new version of add-in express

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

Update add-in with new version of add-in express
 
Posts 1 - 10 of 13
First | Prev. | 1 2 | Next | Last 
nwein




Posts: 577
 Joined: 2011-03-28
We have an Outlook (2010, 32-bit) add-in that is deployed using an msi (aka main add-in).
To facilitate simple updates we've developed an additional add-in, also deployed as an msi that will check for updates (aka updater).
The logic is pretty simple, the updater runs a simple timer that checks for new version of the main add-in. If it identifies a new version it will prompt a message in the outlook client to update the main add-in.
(suffice to say that we don't update the updater frequently, so we don't need an updater for the updater. Hope it makes sense).

When the user agrees to update, the updater basically disconnects the main add-in (((ComAddIn)mainAddIn).Connect = false), runs the main add-in installer and upon successfully exit code from the installer, re-connects the main add-in, thus allowing an update without the need to close the host.
For this to work properly we had to change the main add-in's adxloader.dll.manifest to enable shadow copy.
This entire process is working just fine.
However, now that I'm trying to update my main add-in that was built with ADX 8.1 to use ADX 8.2 the msi update (of the main add-in) is complaining that the process is being used and the update cannot continue. If I still continue (ignoring the warning) the update finishes claiming that i'd need to restart my machine for it to work fine. If I ignore this as well, i.e. don't restart my machine, in fact, not even restarting Outlook (remember, Outlook is always running during this process) my add-in seems to be updated just fine and everything is working fine.

Do you know why would this happen?
One thing that I can think of is that I have updated my updater recently (I know I said we don't do it often) and is now built using 8.2 assemblies. Perhaps that's the problem? (no, see addendum below) Otherwise i'm left with some bad update process whenever there's a new version of add-in Express.

To summarize:
* Updater add-in (ADX 8.2)
* Main add-in (ADX 8.1) update add-in to new version with ADX 8.2 --> msi update warning
* Main add-in (ADX 8.2) update add-in to new version with ADX 8.2 --> works fine


Addendum -
I just tried another scenario as I found and older updater build with ADX 8.1. This doesn't work cleanly either. So my above thought is not correct and there's, apparently, no importance of the updater's ADX assemblies, just the main add-in's assemblies
Posted 12 Aug, 2016 10:59:47 Top
Andrei Smolin


Add-in Express team


Posts: 18825
 Joined: 2006-05-11
Hello Nir,

Is it possible that the updater doesn't disconnect the main add-in?

nwein writes:
is complaining that the process is being used


This relates to adxloader.dll/adxloader64.dll.

If you disconnect the main add-in manually, does the update process work correctly? If yes, then check the code of the updater: it may doesn't release COM references to the COMAddin object representing the main add-in and thus leaves it unloaded.


Andrei Smolin
Add-in Express Team Leader
Posted 15 Aug, 2016 06:19:13 Top
nwein




Posts: 577
 Joined: 2011-03-28
The updater is absolutely disconnecting the main add-in (hence the code snippet I've included above) but thanks for the suggestion, I've just double checked and even if I disconnect the main add-in manually the updater process complains about the process being in used.
There is no way it's an unreleased COM object issue (I can guarantee it!); moreover, the issue is only happening when the main add-in's ADX assemblies are changed - when updating the main add-in to a new version (when the ADX assemblies haven't been updated) the whole process works like a charm. So it must be something to do with the shadow copy of the previous ADX assemblies still being used (or something like that). I'll try to create such a solution (including 2 add-ins) to help you reproduce it in case you can't.
Posted 15 Aug, 2016 10:19:00 Top
nwein




Posts: 577
 Joined: 2011-03-28
Any findings yet? I've sent you a sample solution a couple of days ago
Posted 17 Aug, 2016 10:10:30 Top
Andrei Smolin


Add-in Express team


Posts: 18825
 Joined: 2006-05-11
Hello Nir,

Actually, everything works for me. I've just tested applying a major upgrade after installing several minor updates. The only real omission was AddinExpress.MSO.2005.tlb not excluded in the main setup project. It isn't excluded due to an issue that shows itself when using Visual Studio Installer to create a setup project in VS 2013-2015; please find more details at https://www.add-in-express.com/forum/read.php?FID=5&TID=14056.


Andrei Smolin
Add-in Express Team Leader
Posted 17 Aug, 2016 10:19:58 Top
nwein




Posts: 577
 Joined: 2011-03-28
Have you changed the add-in express assemblies and tried the update? (i.e. AddinExpress.MSO.2005.dll, AddinExpress.OL.2005.dll, adxloader.dll, adxloader64.dll and adxregistrator.exe)
I know that normal updates works, it's just in those situations where the above assemblies/executables change that it doesn't work.
I don't care much about the tlb, I believe I've excluded it myself as well and I can't see that that would be the reason for anything.
Posted 17 Aug, 2016 10:27:01 Top
Andrei Smolin


Add-in Express team


Posts: 18825
 Joined: 2006-05-11
Hello Nir,

I've tested this scenario today. The issue occurs when MSI finds that the loader file(s) must be updated i.e. when the new add-in version uses a different loader. The issue occurs because the loader file gets locked when you call COMAddins(index).

Here's a description of my tests. I start Excel with an add-in loaded and try to move its files to a different folder. This shows that adxloader.dll is locked. I turn the add-in off in the COM add-ins dialog and this unlocks the file. I turn the add-in on (in the COM add-ins dialog) and run a program that accesses COMAddins(index); the program doesn't do anything else. This locks the file: turning the add-in off in the COM Add-ins dialog doesn't unlock the file. To unlock the file, I have to close Excel.


Andrei Smolin
Add-in Express Team Leader
Posted 18 Aug, 2016 08:36:38 Top
nwein




Posts: 577
 Joined: 2011-03-28
Thanks for checking this. It makes sense now (also proves I wasn't lying ;) ).
I'll try to see if there's any way to circumvent that somehow but if not, we'll just have to live with the fact that every so often we'll have to close the host for the update to complete. Thanks again!
Posted 18 Aug, 2016 09:55:52 Top
Andrei Smolin


Add-in Express team


Posts: 18825
 Joined: 2006-05-11
Hello Nir,

nwein writes:
also proves I wasn't lying ;)


))

nwein writes:
I'll try to see if there's any way to circumvent that somehow


If you have an idea, please share it with us. FYI, Marshal.ReleaseComObject returns 0 when I release the Office.COMAddin object.

We are going to publish an Add-in Express build providing automatic updates In September.


Andrei Smolin
Add-in Express Team Leader
Posted 19 Aug, 2016 06:22:30 Top
nwein




Posts: 577
 Joined: 2011-03-28
Hey Andrei, I don't know if you've changed anything in 8.3 but I now can complete this task without an issue by moving the loader file prior to my disconnect (I still can't delete it as it's in use but if it's moved then it's not causing any issues anymore).

Here's a description of my tests. I start Excel with an add-in loaded and try to move its files to a different folder. This shows that adxloader.dll is locked.

This doesn't seem to be the case anymore (actually, I never tried it myself before so I don't know for sure that it wasn't feasible before but i'll take your word).

I saw the updater you guys have introduced in the ClickTwice deployment, however it doesn't do it silently without needing to close the host that's why I'm not using it.
My solution now is complete: checking for updates and when an update is available allowing the update to complete without closing the host, regardless if there are new ADX binaries.
Thanks for getting me on the right track (identifying the loader is the root cause of the problem).
Posted 03 Nov, 2016 18:01:59 Top

Posts 1 - 10 of 13
First | Prev. | 1 2 | Next | Last