Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update creating-app-with-plugin-support.md #43679

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
5 changes: 4 additions & 1 deletion docs/core/tutorials/creating-app-with-plugin-support.md
Original file line number Diff line number Diff line change
Expand Up @@ -8,13 +8,16 @@

agocke marked this conversation as resolved.
Show resolved Hide resolved
# 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:
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Dare I propose "assembly context"?

Copy link
Member Author

@agocke agocke Nov 20, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?


- 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.

Check failure on line 19 in docs/core/tutorials/creating-app-with-plugin-support.md

View workflow job for this annotation

GitHub Actions / lint

Trailing spaces

docs/core/tutorials/creating-app-with-plugin-support.md:19:292 MD009/no-trailing-spaces Trailing spaces [Expected: 0 or 2; Actual: 1] https://github.com/DavidAnson/markdownlint/blob/v0.36.1/doc/md009.md
agocke marked this conversation as resolved.
Show resolved Hide resolved

## Prerequisites

- Install the [.NET 5 SDK](https://dotnet.microsoft.com/download) or a newer version.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should we update versions here? 5 is EOL

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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."

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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+

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I like that

Expand Down
Loading