You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/reference/extensibility/NuGet-Cross-Platform-Plugins.md
+33-40Lines changed: 33 additions & 40 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -12,20 +12,11 @@ ms.topic: conceptual
12
12
In NuGet 4.8+ support for cross platform plugins has been added.
13
13
This was achieved with by building a new plugin extensibility model, that has to conform to a strict set of rules of operation.
14
14
The plugins are self-contained executables (runnables in the .NET Core world), that the NuGet Clients launch in a separate process.
15
-
This is a true write once, run everywhere plugin. It will work with all NuGet client tools.
16
-
The plugins can be either .NET Framework (NuGet.exe, MSBuild.exe and Visual Studio), or .NET Core (dotnet.exe).
17
-
A versioned communication protocol between the NuGet Client and the plugin is defined. During the startup handshake, the 2 processes negotiate the protocol version.
18
-
19
-
In order to cover all NuGet client tools scenarios, one would need both a .NET Framework and a .NET Core plugin.
20
-
The below describes the client/framework combinations of the plugins.
21
-
22
-
| Client tool | Framework |
23
-
| ------------ | --------- |
24
-
| Visual Studio | .NET Framework |
25
-
| dotnet.exe | .NET Core |
26
-
| NuGet.exe | .NET Framework |
27
-
| MSBuild.exe | .NET Framework |
28
-
| NuGet.exe on Mono | .NET Framework |
15
+
This is a true write once, run everywhere plugin.
16
+
It will work with all NuGet client tools.
17
+
The plugins can be written in any programming language, but the easiest plugin development and installation experience will be with .NET.
18
+
A versioned communication protocol between the NuGet Client and the plugin is defined.
19
+
During the startup handshake, the 2 processes negotiate the protocol version.
29
20
30
21
## How does it work
31
22
@@ -41,18 +32,15 @@ The high level workflow can be described as follows:
41
32
The current protocol version is *2.0.0*.
42
33
Under this version, the requirements are as follows:
43
34
44
-
- Have a valid, trusted Authenticode signature assemblies that will run on Windows and Mono. There is no special trust requirement for assemblies run on Linux and Mac yet. [Relevant issue](https://github.com/NuGet/Home/issues/6702)
45
35
- Support stateless launching under the current security context of NuGet client tools. For example, NuGet client tools will not perform elevation or additional initialization outside of the plugin protocol described later.
46
36
- Be non interactive, unless explicitly specified.
47
37
- Adhere to the negotiated plugin protocol version.
48
38
- Respond to all requests within a reasonable time period.
49
39
- Honor cancellation requests for any in-progress operation.
50
-
-**Starting with NuGet 6.13, executable plugins (including global .NET tools) must follow these requirements:**
51
-
- Naming Convention: Must follow the pattern `nuget-plugin-*`.
52
-
- Windows:
53
-
- Must be either `.exe` or `.bat` files.
54
-
- Linux:
55
-
- Must have their executable permissions enabled.
40
+
41
+
Plugins discovered from the PATH environment variable (for example, installed via `dotnet tool`) additionally must match the filename pattern `nuget-plugin-*`.
42
+
43
+
NuGet 6.12 (MSBuild 17.12, and .NET SDK 9.0.100) and earlier also required plugins to be Authenticode signed on Windows.
56
44
57
45
The technical specification is described in more detail in the following specs:
58
46
@@ -72,30 +60,27 @@ After 1 minute of inactivity a plugin is considered idle and is shut down.
72
60
73
61
## Plugin installation and discovery
74
62
75
-
The plugins will be discovered via a convention based directory structure.
76
-
CI/CD scenarios and power users can use environment variables to override the behavior. When using environment variables, only absolute paths are allowed. Note that `NUGET_NETFX_PLUGIN_PATHS` and `NUGET_NETCORE_PLUGIN_PATHS` are only available with 5.3+ version of the NuGet tooling and later.
63
+
NuGet searches for plugins from a convention based directory structure, and scanning the PATH environment variable.
64
+
65
+
### Convention based discovery
66
+
67
+
CI/CD scenarios and power users can use environment variables to override the behavior.
68
+
When using environment variables, only absolute paths are allowed. Note that `NUGET_NETFX_PLUGIN_PATHS` and `NUGET_NETCORE_PLUGIN_PATHS` are only available with 5.3+ version of the NuGet tooling and later.
77
69
78
70
-`NUGET_NETFX_PLUGIN_PATHS` - defines the plugins that will be used by the .NET Framework based tooling (NuGet.exe/MSBuild.exe/Visual Studio). Takes precedence over `NUGET_PLUGIN_PATHS`. (NuGet version 5.3+ only)
79
71
-`NUGET_NETCORE_PLUGIN_PATHS` - defines the plugins that will be used by the .NET Core based tooling (dotnet.exe). Takes precedence over `NUGET_PLUGIN_PATHS`. (NuGet version 5.3+ only)
80
-
-`NUGET_PLUGIN_PATHS`
81
-
- defines the plugins that will be used for that NuGet process, priority preserved. If this environment variable is set, it overrides the convention based discovery. Ignored if either of the framework specific variables is specified.
82
-
83
-
-**Starting with NuGet 6.13:**
84
-
- Can specify paths to executable plugin files, including .NET tools plugins.
85
-
- Supports both file paths and folders containing plugin files.
- User-location, the NuGet Home location in `%UserProfile%/.nuget/plugins`. This location cannot be overriden. A different root directory will be used for .NET Core and .NET Framework plugins.
-`NUGET_PLUGIN_PATHS` - defines the plugins that will be used for that NuGet process, priority preserved. If this environment variable is set, it overrides the convention based discovery. Ignored if either of the framework specific variables is specified.
73
+
- User-location, the NuGet Home location in `%UserProfile%/.nuget/plugins`. This location cannot be overridden. A different root directory will be used for .NET Core and .NET Framework plugins.
| .NET Framework |`%UserProfile%/.nuget/plugins/netfx`| MSBuild, NuGet.exe, Visual Studio |
94
79
95
80
Each plugin should be installed in its own folder.
96
81
The plugin entry point will be the name of the installed folder, with the .dll extensions for .NET Core, and .exe extension for .NET Framework.
97
82
98
-
```
83
+
```text
99
84
.nuget
100
85
plugins
101
86
netfx
@@ -110,8 +95,16 @@ The plugin entry point will be the name of the installed folder, with the .dll e
110
95
...
111
96
```
112
97
113
-
> [!Note]
114
-
> There is currently no user story for the installation of the plugins. It's as simple as moving the required files into the predetermined location.
98
+
### PATH discovery
99
+
100
+
Starting from [NuGet 6.13](../../release-notes/NuGet-6.13.md), NuGet will search each directory provided in the PATH environment variable for files matching the pattern `nuget-plugin-*`.
101
+
On Windows the file must have an `.exe` or `.bat` extension.
102
+
On Linux and Mac the file must have the executable bit set.
103
+
104
+
This allows NuGet plugins to be installed via `dotnet tool` commands, WinGet, a Linux distribution's package manager, or any other method that can put executables on the user's PATH.
105
+
This also allows NuGet plugins to be written in any programming language (previously plugins for Linux and Mac must be written in .NET).
106
+
107
+
We recommend plugins are developed in .NET, so that you can use the [NuGet.Protocol package](https://www.nuget.org/packages/NuGet.Protocol) to avoid needing to write the json RPC code, and to allow customers to discover your plugin via `dotnet package search nuget-plugin`.
0 commit comments