Update creating-app-with-plugin-support.md #43679
Conversation
| @@ -8,13 +8,16 @@ ms.date: 10/16/2019 | |||
|
|
|||
| # Create a .NET Core application with plugins | |||
|
|
|||
| This tutorial shows you how to create a custom <xref:System.Runtime.Loader.AssemblyLoadContext> to load plugins. An <xref:System.Runtime.Loader.AssemblyDependencyResolver> is used to resolve the dependencies of the plugin. The tutorial correctly isolates the plugin's dependencies from the hosting application. You'll learn how to: | |||
| This tutorial shows you how to create a custom <xref:System.Runtime.Loader.AssemblyLoadContext> to load plugins. An <xref:System.Runtime.Loader.AssemblyDependencyResolver> is used to resolve the dependencies of the plugin. The tutorial provides a separate namespace for the plugin's dependencies, allowing different assembly dependencies between the plugins and the hosting application. You'll learn how to: | |||
There was a problem hiding this comment.
What does "namespace" in this sentence refer to? I don't think the C# namespace is what is implied here and using that term is likely to cause more confusion.
There was a problem hiding this comment.
Dare I propose "assembly context"?
There was a problem hiding this comment.
Namespace meaning that type names do not necessarily resolve to the same types. I really don't know a better runtime term for that.
That is, Newtonsoft.JSON.JsonObject in one context does not necessarily refer to the same type as Newtonsoft.JSON.JsonObject in another ALC.
On the one hand this doesn't feel like a very well-known term. On the other hand, should it be? I think this provides the best mental model I have when thinking about ALCs.
There was a problem hiding this comment.
That is, Newtonsoft.JSON.JsonObject in one context does not necessarily refer to the same type as Newtonsoft.JSON.JsonObject in another ALC.
Right. "Assembly context", as proposed in #43679 (comment), is what I would use.
|
|
||
| - Structure a project to support plugins. | ||
| - Create a custom <xref:System.Runtime.Loader.AssemblyLoadContext> to load each plugin. | ||
| - Use the <xref:System.Runtime.Loader.AssemblyDependencyResolver?displayProperty=fullName> type to allow plugins to have dependencies. | ||
| - Author plugins that can be easily deployed by just copying the build artifacts. | ||
|
|
||
| > [!NOTE] | ||
| > .NET does not provide a security or reliability boundary beyond the operating system's process boundary. Untrusted code cannot be safely loaded into a trusted .NET process. To provide a security or reliability boundary, consider a technology provided by your OS or virtualization platform. | ||
|
|
||
| ## Prerequisites | ||
|
|
||
| - Install the [.NET 5 SDK](https://dotnet.microsoft.com/download) or a newer version. |
There was a problem hiding this comment.
should we update versions here? 5 is EOL
There was a problem hiding this comment.
Do we update everywhere that we mention a version in the docs on a regular basis? I think this is fine because it says "or a newer version."
There was a problem hiding this comment.
typically you don't want to have EOL versions like this. the warning later on says that the code shows .NET 5 code but the that the feature was introduced in 3.0. I think saying when it was introduced is fine but IMHO the article should say .NET 8 or later versions and the code should work in 8+
There was a problem hiding this comment.
but IMHO the article should say .NET 8 or later versions and the code should work in 8+
I disagree. I think that just puts us in the same position WRT to EOL versions when .NET 8 eventually goes out of support. The only future-proof option is to avoid recommending any specific version for installation. I don't know what we do about samples that have to contain a TFM. It seems unavoidable that we will end up with EOL versions in those places.
I think we need to agree on one of two approaches: either we're OK with older versions appearing in docs/samples, or someone is put in charge of sweeping all the docs for EOL versions every time a version goes out of support. Piecemeal approaches will not leave us in a good state.
There was a problem hiding this comment.
I would remove the text about which SDK this is supported in entirely. I don't think we have a responsibility for explaining that a feature doesn't work in an SDK that has been EOL for quite some time.
There was a problem hiding this comment.
I would remove the text about which SDK this is supported in entirely.
Yeah, I agree. For this case I think we can just remove mention of the specific version. For samples that have to contain some "netxx" we need to come up with a plan there.
Co-authored-by: Aaron Robinson <[email protected]>
| --- | ||
|
|
||
| # Create a .NET Core application with plugins | ||
|
|
||
| This tutorial shows you how to create a custom <xref:System.Runtime.Loader.AssemblyLoadContext> to load plugins. An <xref:System.Runtime.Loader.AssemblyDependencyResolver> is used to resolve the dependencies of the plugin. The tutorial correctly isolates the plugin's dependencies from the hosting application. You'll learn how to: | ||
| This tutorial shows you how to create a custom <xref:System.Runtime.Loader.AssemblyLoadContext> to load plugins. An <xref:System.Runtime.Loader.AssemblyDependencyResolver> is used to resolve the dependencies of the plugin. The tutorial provides a separate namespace for the plugin's dependencies, allowing different assembly dependencies between the plugins and the hosting application. You'll learn how to: |
There was a problem hiding this comment.
We use "isolated" in number of other assembly load context docs.
For example, https://learn.microsoft.com/en-us/dotnet/core/dependency-loading/understanding-assemblyloadcontext#what-is-the-assemblyloadcontext says "creates an isolated context for loading code and its dependencies". Fix those too for consistency?
Internal previews