Wox: Update plugins without the need to restart (with possible solution)

[Sire]

There are ways of updating plugins on the fly (while the app is running). Here is a very good (and simple) open source library that works great:
http://www.codeproject.com/Articles/182970/A-Simple-Plug-In-Library-For-NET

This might also aid your auto-update case in the later milestone.

[qianlifeng]

Sorry for this so late reply, But I tried the demo he provided, I also can't update the plugin dll when application is running.

[qianlifeng]

I also tried isolate appdomain per-plugin approach. But performance is not good for me, We have to use marshal to invoke methods.

[Sire]

Works fine for me, and I doubt there are any performance problems. Try this modified sample. I added a "refresh" button. Start the host, copy the file from PluginsTmp to Plugins and click Refresh.
https://dl.dropboxusercontent.com/u/22112966/Calculator.zip

[qianlifeng]

I think you mean it works for dynamic loading new plugins. Wox can do that in current plugin architecture. But both of them can't update plugin without restart host. If you try to replace add.dll when host running, you will get warning which says add.dll is being used by another process, and this will prevent Wox updating plugins on the fly.

About per appdomain performance. You can see this:
http://stackoverflow.com/questions/1144459/what-is-the-minimum-cross-appdomain-communication-performance-penalty

I have tried this in Wox, the plugin which takes 5ms to init will take 100ms at lease if using isolate appdomain approach.

[Sire]

You're right, I did not consider replacing dlls. Not even MEF has solved this, because of limitations in .NET (source: http://stackoverflow.com/a/14842417/2440).

I think the easiest solution for Wox might be to just restart the program when a plugin update is detected. No important state will go missing anyway right?
(Perhaps together with a shadow copy solution so plugin files can be overwritten).

Debugging plugins will still be cumbersome however :(

[qianlifeng]

shadow copy still need a restart to load updated plugins. It seems there is no other better solutions except restarting Wox right now.

You are right, debugging plugins is still be cumbersome. Currently, I added new plugin project to Wox solution and then do the development and debug.

[orzFly]

So maybe we can put plugins into subfolders named with its version. Doing
so enable the program to unload old assembly and load new assembly without
restarting Wox.

We can purge old version folders durning next start.
On Jan 21, 2015 11:10 PM, "qianlifeng" [email protected] wrote:

shadow copy still need a restart to load updated plugins. It seems there
is no other better solutions except restarting Wox.

You are right, debugging plugins is still be cumbersome. Currently, I
added new plugin project to Wox solution and then do the development and
debug.

—
Reply to this email directly or view it on GitHub
https://github.com/qianlifeng/Wox/issues/184#issuecomment-70853658.

[qianlifeng]

@orzFly After assembly loaded into appdomain, you can't just unload assembly. If you want to unload assembly, you need to unload the whole appdomain. See this: https://msdn.microsoft.com/en-us/library/ms173101.aspx

[bao-qian]

This is possible.
There could be multiple Appdomain, and Appdomain can be subdivided into object context.

[Sire]

I stumbled on this possible solution, but perhaps it would be too much of a compromise:
http://www.ikriv.com/dev/wpf/BaktunShell/index.shtml
Mentioned in this article:
http://www.codeproject.com/Articles/635497/AppDomains-Wont-Protect-Host-From-a-Failing-Plugin

[bao-qian]

@Sire Thanks for your info. As you can see from the milestone, this is not the current focus. I will look into this in the future.

[bao-qian]

bad news

App Domains
Why was it discontinued? AppDomains require runtime support and are generally quite expensive. While still implemented by CoreCLR, it’s not available in .NET Native and we don’t plan on adding this capability there.

https://blogs.msdn.microsoft.com/dotnet/2016/02/10/porting-to-net-core/

combined with https://github.com/Wox-launcher/Wox/issues/184#issuecomment-153689163 ,
so perhaps just use multi process (aka json communication) for all plugins ?

[Sire]

Three years later :)

I've now evaluated both MEF (Managed Extensibility Framework) and MAF (Managed AddIn Framework, System.AddIn) and MAF seems like a great potential for Wox.

It can handle adding new plugins at runtime and also updating existing plugins runtime (as long as they are in a different folder or have a different dll name). I have sample code if you want to check it out in the future.

https://stackoverflow.com/questions/835182/choosing-between-mef-and-maf-system-addin