Posts 1 - 10 of 14
First | Prev. | 1 2 | Next | Last
|
|
|
|
nwein
Posts: 577
Joined: 2011-03-28
|
Hello again,
I've asked https://www.add-in-express.com/forum/read.php?PAGEN_1=1&FID=5&TID=14052#nav_start a long time ago but it looks like things have changed since.
My original solution to update my Outlook COM addin was to have another addin, called Updater, checking for updates and when it found an update it would (prompt the user first and then) unload the main add-in, using Connect = false, move any adxloader files to a temp folder, and run the update msi which would then update all the files, including the adxloader. Finally, it connects the (new) addin by setting it Connect to true - all while the host is running.
Now, this method was working in the past. However, after a couple of years, and with us having Outlook 2016 64-bit as well (original solution was only for Outlook 2010 32-bit), and many ADX version later (had it working with 8.3), things seem to have stopped working properly.
I mean, the process still goes off without any errors, the add-in folder have all the updated files, but when the add-in is connected again the loaded my.addin.dll is still the old one, (e.g. if upgraded from version 1.0.0 to 2.0.0 then the 1.0.0 version is still loaded in Outlook, even when there's sign of that reference anywhere, definitely not in the place where the add-in is installed).
This doesn't seem to be an implementation issue either, since doing this whole process manually (i.e. disabling the add-in from the COM Addin dialog, deleting and moving all the files from the installation path, running the msi to update, verifying that the add-in folder now contains all the new files, and then loading the updated add-in through the COM addins dialog, again all while the host is running) returns the same result. This used to work in Outlook 2010 32-bit a long time ago.
I also found it interesting that when I disable my add-in I can see it still being loaded in its own app domain in Outlook. I thought it would get unloaded but that's not the case.
My question is, again, is it possible to achieve what I was doing in the past, again? why does Outlook keeps the addin loaded even though it's not connected (even removing the add-in from the COM add-in dialog doesn't change anything).
I've tried playing with shadow copy and with load behaviour but nothing seems to work.
I would certainly love to use the auto update mechanism you guys have, but my requirement state that the host MUST be running through the update process. |
|
|
Posted 05 Feb, 2019 09:11:24
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
|
|
Posted 05 Feb, 2019 09:54:04
|
|
Top
|
|
|
nwein
Posts: 577
Joined: 2011-03-28
|
Yes, glad to be back working on some add-ins :)
We'll check if this is something caused by our code.
Yes, I used process explorer to identify it as well.
I've just tested my app after downgrading my adx from 9.2 to 8.7 and it works fine now.
I tested it also with 9.1 and it was broken, so somewhere between (8.8-9.1) it got broken.
Unfortunately I don't have the other version available (and the license key doesn't seem to work for older versions past 9.1) so I can't tell you which exact version broke it but I'm sure you can find out :)
Thanks for looking into it! |
|
|
Posted 05 Feb, 2019 10:56:06
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Nir,
This isn't caused by Add-in Express. On my machine, I register an empty COM add-in for Excel, start Excel 16.0.11326.20000 (it's Office Insider) and rename files in the output folder of my project (the add-in is registered in this folder), turn the add-in off and on - it continues to work despite the renamed files. I've renamed the loader, manifest, add-in assembly, and .tlb file.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 06 Feb, 2019 10:45:21
|
|
Top
|
|
|
nwein
Posts: 577
Joined: 2011-03-28
|
Not sure what to make of it, but the matter of fact is that you can see the add-in's app domain being unloaded when you uncheck the addin in the COM addin dialog when using an older version of ADX (8.7.4425.0 for example); on the other hand, when using the exact same code, just with a later version of ADX (9.1 or 9.2 for example), the add-in's app domain remains in the host when unchecking the addin in the COM addin dialog.
I've done my tests with Outlook so I don't know if it's any different with Excel.
I just downgraded our add-in to use 8.7 and our updater mechanism works flawlessly. |
|
|
Posted 06 Feb, 2019 11:01:46
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Nir,
Supposedly, we've found a way to make the 9.2 loader to behave in the way the 8.7 loader does. In a couple of minutes, I'll send you an email with the code line to invoke in your code.
Anyway, Microsoft doesn't provide and Add-in Express doesn't support updating add-ins on the fly. The supported way is to turn the host application off, update the files and then restart the host application.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 08 Feb, 2019 05:58:01
|
|
Top
|
|
|
nwein
Posts: 577
Joined: 2011-03-28
|
Thanks Andrei,
I know what the supported way is, but since we found a way to circumvent that (and really, wouldn't anyone prefer to not restart their host to update?) we'd like to continue doing so.
Regardless of anything, even if we're not updating or what, i'd expect the add-in to be unloaded when I disable it, much like it does for any other non-adx add-in and/or adx add-ins versioned 8.7 or lower. |
|
|
Posted 08 Feb, 2019 10:19:16
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Nir,
Although everyone - and we are the first in this line - would prefer to get their extensions updated on the fly, this isn't supported. What you do comes at a price: your loader isn't updated and this makes your deployment vulnerable. We don't recommend using this. I know that you know what we recommend but I need to emphasize: your deployment method is not recommended. I hope the code line I sent to you works for you. I also hope you have some mechanism to synchronize the version of the loader and AddinExpress.MSO.2005.dll.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 11 Feb, 2019 09:51:21
|
|
Top
|
|
|
nwein
Posts: 577
Joined: 2011-03-28
|
Hello Andrei,
I hope the code line I sent to you works for you
Unfortunately I haven't received any email from you guys so I can't test it.
What you do comes at a price: your loader isn't updated
I'm not sure I follow. I'm replacing all of my assemblies when I update, the adxloader, the mso.2005, everything.
The only "price" I pay here, is having to develop and deploy another add-in (albeit, only once. Ever) that its sole purpose it to update the main one, but in the grand scheme of things, once you have that, everything else is streamlined (you can also use one updater to update multiple other add-ins if you'd like) and the code can be re-used. |
|
|
Posted 11 Feb, 2019 11:54:19
|
|
Top
|
|
|
Andrei Smolin
Add-in Express team
Posts: 18817
Joined: 2006-05-11
|
Hello Nir,
nwein writes:
Unfortunately I haven't received any email from you guys so I can't test it.
Please check your Junk Email. If it isn't there, please provide another email address and I'll resend it.
nwein writes:
I'm replacing all of my assemblies when I update, the adxloader, the mso.2005, everything.
I'm at loss. In my tests, turning an add-in off leaves the loader dll file locked if I use that code line.
Andrei Smolin
Add-in Express Team Leader |
|
|
Posted 12 Feb, 2019 04:48:50
|
|
Top
|
|
|
Posts 1 - 10 of 14
First | Prev. | 1 2 | Next | Last
|
Forums
Topics
Search
Help
Login
Register