Port and update System.Addin

[mms-]

Though not used massively there is a real use for it, and as far as I know nothing to replace it. UWP environment as it grows will want this functionality to support business apps.

[RichiCoder1]

Maybe I don't understand the purpose of System.AddIn, but from a brief read wouldn't it be supplanted by System.Composition aka MEF? Especially since MAF requires AppDomains, something that doesn't exist in Core?

[mms-]

There is some overlap, and MEF could be extended, but these solve different problems, please see : http://stackoverflow.com/questions/835182/choosing-between-mef-and-maf-system-addin

Ideally a new MAF implementation would use MEF where appropriate. AppDomains aren't required it's just one of the options, process isolation is more important.

.Net Core is new and it will evolve. If UWP/Core are to eventually take over from win32 apps, strong support for IPC and process isolation (i.e. what most web browsers use for tabs) are required.

[RichiCoder1]

Described like that, the Omnisharp folks immediately come to mind. Thoughts @david-driscoll?

[danmoseley]

This is not in the Mono mobile subset.

[net456]

I use System.AddIn to load components at runtime, it would be great to have it in the core, any updates on this?

[karelz]

@maxim-reutov please upvote the top post. Currently we do not have plans to bring it over.
If there is strong community interest, we can help kick start the port and leverage community contributions to make it compile and add tests.

[net456]

@karelz ok thanks for the update, we use AddIns as one of the core components in our product. Our product aggregates a number of different systems that have the same interface but different implementation, once product is deployed we might release new system or update existing then product can download it from the main server and start using it without any service interruption, AddIn framework allows us to load and unload components at run time in separate app domains, which is a very powerful feature, we can easily extend the product at runtime. On the roadmap we are thinking to migrate the product to .Net Core and be able to use Docker containers to deploy it to other platforms. I would be happy to contribute to this project and will try to generate more community interest:)

[karelz]

.NET Core does not support AppDomains (and never will be). Is System.AddIn still interesting for you without AppDomains support?

[net456]

I used app domains in order to be able unload and reload updated AddIn. Updating of loaded AddIns was the the only reason I needed App Domains. Unloading/updating existing AddIns is important but not critical, more important is the ability to load new AddIns.

Currently AddIn can be activated in:

1. Current process/specified app domain
2. Current process/new app domain
3. New process/new app domain
   https://msdn.microsoft.com/en-us/library/system.addin.hosting.addintoken.activate(v=vs.110).aspx

Which activation options can be supported with .NET Core? I think it uses new app domains to avoid possible conflicts between loaded assemblies versions, new process would do that but probably will be complicated to implement. It can try to load all AddIns into the same process (current implementation allows to do that) but then not sure if it will be able to support unloading of the AddIns (but maybe yes, not sure).

[karelz]

@maxim-reutov unloading assemblies from process is hard - there is community effort to do it in dotnet/corefx#14724, but obviously no ETA/guarantee.
Current process or new process are the only activation options on .NET Core.

[net456]

@karelz yup, AddIns used AppDomains for that. New process would definitely work as well. Unloading AddIns from the current process could be combined with that task, that's mostly what AddIns are about - loading/unloading and isolating a set of assemblies. As a first step we can implement AddIns hosted in the same process (without unloading) and then hosted in another process with unloading, and then maybe when that task gets implemented can also support unloading from the same process, my 5 cents:)

[karelz]

@maxim-reutov what's inter-process communication that AddIn uses?
Wouldn't it be easier to use MEF (System.Composition) as mentioned above?

[mms-]

MEF does not deal with IPC, it's for dependency injection.. please read http://stackoverflow.com/questions/835182/choosing-between-mef-and-maf-system-addin for the specifics.

AppDomain is not required, process isolation is often required anyway, such as when running buggy third party code which would otherwise bring down your entire app.

As UWP apps get bigger the same problems that MAF solves will need solving.. it's not a question of weather MAF (or something like it) is needed it's just a question of should the framework have it or not. Since it's common? for larger apps to use this it should go in the framework. Note the distinction between small app/big app is blurring (think about a phone needing to run a full on desktop app when connected to a monitor, as in Continuum), all hardware these days (or very soon) can handle the same framework and app code (no need to drop types such as in Silverlight to bring down the size).

A single, scalable, componentized framework is the only way to go. The sooner win32, WPF, MSI, etc. die, the sooner there is an actual replacement, the better. The current fragmentation in Windows dev is not helping anyone especially Microsoft.

[net456]

@karelz - I don't think MEF can support what MAF does, main advantage of MAF that it can load and unload AddIns at runtime, so if my client is using my product and I publish updated AddIn at my server then client can unload existing version of AddIn and reload updated version all at runtime without any service interruption, so I can extend product easily without affecting clients code. You can try to achieve the same result using other techniques but the MAF framework solves this problem in the best way.

https://msdn.microsoft.com/en-us/library/dd460648(v=vs.110).aspx:
Quote - "Previous versions of the .NET Framework introduced the Managed Add-in Framework (MAF), designed to allow applications to isolate and manage extensions. The focus of MAF is slightly higher-level than MEF, concentrating on extension isolation and assembly loading and unloading, while MEF's focus is on discoverability, extensibility, and portability. The two frameworks interoperate smoothly, and a single application can take advantage of both."

MAF framework is kind of complicated to use, but once you set everything up, create the pipeline thru which components communicate then extending the application becomes very easy, there is a nice tool that can create the pipeline called Pipeline Builder, simplifies many things:)

Here's an overview of how things are connected there:
https://msdn.microsoft.com/en-us/library/bb384200(v=vs.110).aspx

You create contracts thru which host and AddIn communicate thru the pipeline and a set of adapters that transfer data thru app domain or process boundaries.

As for the inter process communication, I only used AddIns with AppDomains since it is more efficient but not with external processes, it would be interesting so see how it is implemented. I would assume it can use some form of shared memory communication to transmit complex data types, I used it on Linux back in my operating systems class very long time ago:)
I'm thinking that for .Net Core, if it supports AddIns it might be cleaner to load them in external processes, that provides ultimate isolation, the only problem is interprocess communication but you mentioned that other parts of .Net Core support that so it might be possible to implement.

[RichiCoder1]

@maxim-reutov I think you meant @karelz. And it sounds like you're basically looking for MEF + blessed IPC + blessed OOP/Isolated hosting? (blessed here refering to in corefx).

[net456]

@RichiCoder1 thanks, corrected that.. well pretty much yes, but then it would be equal to MAF. I need a way to load/unload components at run time, MAF was the solution, it would be great if I could do similar in the Core. I have an application that is able to update itself at runtime by using MAF. I couldn't find anything else that would do assembly unloading and being able to support multiple versions of the same assembly.

[LTAcosta]

We're currently using MAF in an enterprise product to embed customer written UI AddIns. The primary benefits for us are process isolation and assembly unloading. It is also nice to have a framework in place to support our 3 API versions, that all work seamlessly in several of our products. I would love to see some form of this ported to Core.

[karelz]

I spoke with folks who have some background on System.AddIn. The technology, incl. the API surface relies heavily on Remoting for cross-domain/cross-process communication. Remoting is a large beast and it is not something we have (or want) in .NET Core. As such, I am afraid any attempt to truly port System.AddIn API surface or code is doomed.

The good news is that AssemblyLoadContext can satisfy one of the requirements above -- the ability to load multiple versions of the same assembly in the same process.
Unloading assemblies can potentially light up via dotnet/corefx#14724.

Given the features above, I wonder if there are other missing pieces which would enable creation of new APIs to achieve the functionality and flexibility of System.AddIn from Desktop.

[mms-]

Definetly makes sense about .Net Remoting. What is the recommended replacement for .Net Core/UWP inter process comm.? WCF seems to have it's own limitations on these platforms.

Is System.Addin open source?

[karelz]

System.AddIn has available source code on ReferenceSource: https://referencesource.microsoft.com/#System.AddIn/System/Addin/Hosting/Store/AddIn.cs,de4c6dc050ca2e23
It is not part of the new one with MIT license https://github.com/Microsoft/referencesource

I don't think we provide any IPC layer on .NET Core - you might need to use WCF, Networking or OS IPC primitives.
cc @jkotas if he has other ideas/suggestions for IPC on .NET Core

[net456]

@karelz - thanks for the update, I think those two pieces would support major part of the AddIn functionality, so it should be possible to load a set of assemblies for 1 component (AddIn) and then unload them. I think the last piece is the communication between the components. AddIn provides a pipeline - set of contracts and adapters thru which components communicate. I wonder how that would work with AssemblyLoadContext, would have build a custom communication mechanism thru some form of reflection or migrate it from AddIn.Pipeline. It would be great if behind the covers it used AssemblyLoadContext with unload capabilities but also supported the communication pipeline.

[karelz]

Overall it looks like we will need a brand new API surface (System.AddIn2) to achieve the goals of original System.AddIn.
It would be great to see such effort as independent NuGet package, it does not have to be in CoreFX repo as it does not have any direct ties to it.

Closing the issue as straightforward porting of System.AddIn to .NET Core is not actionable.