AddinManager.Registry.Update failed when add new addin
xiexin36 opened this issue · 5 comments
I call AddinManager.Registry.Update just after
AddinManager.Initialize. The problem is that the application doesn't
see any new addins until the application has been stopped and
restarted. Even those old addins which have be found. In monodevelop, I found it will call AddinManager.Registry.Rebuild when failed, I also try this way, but it doesn't work for me, if every time I delete the adding config directory, it will be OK.
Is this behavior by design or am I doing something wrong?
Thanks.
What you do is correct and should work. If you are using the latest Mono.Addins version then maybe you found a bug. Try providing a console progress monitor in the Update call, with verbosity set to max. Maybe this will print an error you are missing.
Hi slluis, Thank you for your reply.
I searched this problem by Google, and I found this https://groups.google.com/forum/#!searchin/mono-addins/AddinManager.Registry.Update/mono-addins/QMTfoVWfSEc/j97DXSjC4gcJ , the same problem,
Today I test it again, unfortunately it only appear when release build.
Hi slluis, I can also see the same behavior with 1.3. The only workaround currently is to start the application once more, then the add-ins show up as expected.
In addition to my last comment, I just want to add more steps to reproduce. So I have an add-in registered for my application which works fine. I am doing an initialize with a followed update call during application startup. Now running a touch on the add-in dll (just to update the timestamp) results in an empty extension list. The output looks like:
Using assembly reflector: Mono.Addins.CecilReflector.Reflector
Folders scan completed (405 ms)
Generating add-in extension maps
Doing a partial registry update.
Add-ins to be updated:
Add-ins whose relations have to be updated:
Registering new extensions:
Addin relation map generated.
Addins Updated: 0
Extension points: 0
Extensions: 0
Extension nodes: 0
Node sets: 0
Add-in relations analyzed (31 ms)
Hello World!
After some further investigation it seems I have tracked down the problem. The issue occurs if there is a root add-in located in the Global Assembly Cache (GAC). During the first scan this add-in will be added with a domain e.g. "1". Then after adding another add-in, the framework tries to get the description for the GAC add-in from the "global" domain which is not available.