Open JohnSchmeichel opened 1 year ago
FWIW, some intelligent person proposed the same thing a few years ago :)
FWIW, some intelligent person proposed the same thing a few years ago :)
Love it! Definitely worth considering incorporating some of those ideas into this proposal as well, like the new package type and discovery.
Team Triage: @kartheekp-ms it would be good to have a design by 2023-09.
What's the high level idea for detecting a nuget plugin Vs any other .net tool? You wouldn't want to run every installed tool with -Plugin
There's no design for this feature yet. That's something that whoever proposes a design needs to figure out.
Personally, I don't think that cred providers should be installed via dotnet tool install
. Instead, I proposed something else. However, someone needs to create an actual spec with a design that goes through a review.
NuGet Product(s) Affected
NuGet.exe, MSBuild.exe, dotnet.exe, NuGet SDK
Current Behavior
Currently, credential providers support *.exe for .NET Framework or *.dll for .NET Core, and are usually split between two folders under the NuGet credential provider base path. For .NET Framework the providers are discovered by searching credentialprovider.exe and executing that program, and for .NET Core they are discovered by searching credentialprovider.dll and executing
dotnet <credentialprovider>.dll
. Prior to .NET Core 2.0 this split was required as .NET Core only supported platform agnostic dll's (with the side affect of excluding platform dependent credential providers not based on .NET). With the latest versions of .NET however, this split is no longer necessary and requires multiple versions to be supported and deployed. This is also reinforced by the two plugin path environment variablesNUGET_NETFX_PLUGIN_PATHS
andNUGET_NETCORE_PLUGIN_PATHS
which need to be set per framework version.A deployment solution for dotnet is .NET tools which provide a seamless .NET install and management experience for NuGet packages. Using .NET tools as a deployment mechanism has been a recurring feature ask for users of the .NET ecosystem which need to authenticate with private repositories. The ideal workflow would be (for private repositories like Azure DevOps):
dotnet tool install -g Microsoft.CredentialProviders
dotnet restore
with a private endpoint and it 'just works' (e.g. credential providers from step 2 are used during credential acquisition and used to authenticate against private endpoints)This almost works today, but for Windows .NET Framework only. The goal is to support this cross-platform for all supported .NET runtimes.
Problems
This work for Windows and .NET Framework today with the following caveats:
Deployment via a .NET tool doesn't work for .NET Core or cross platform for the following reasons:
For Linux/OSX the executable will not have any extension, but instead just have an executable with the execute bit (+x) set on it. E.g.:
This doesn't work as NuGet is exclusively looking for .exe or .dll
Desired Behavior
The following changes in behavior would be required to make the proposal work:
1. Support platform appropriate executables
For Windows: support *.exe for both .NET Framework and .NET Core. For Linux/OSX: support extensionless executables (+x bit set).
2. Support single plugin path environment variable
In order to ship a single credential provider that works for both .NET Framework and .NET Core that doesn't conflict with the existing semantics of the
NUGET_NETFX_PLUGIN_PATHS
andNUGET_NETCORE_PLUGIN_PATHS
environment variables, a new environment variable should be introduced that supports the new semantics for # 1 above. It's possible thatNUGET_PLUGIN_PATHS
can be repurposed here, but that currently has lower precedence that the framework versions.3. Support the .NET tool default installation location for credential providers
The default .NET tool installation directory should be included when discovering credential providers. This will simplify the installation and should reduce cases where tools are installed to a location that NuGet does not consider, reducing troubleshooting and support cases.
Additional Context
The overall context and vision for the credential providers that support Azure DevOps (nuget, npm, python, etc.) is that they should be supported and easily installable in the ecosystems they are used in. For .NET using the dotnet CLI that means installable using dotnet tool install, for npm that means npm install, etc. Currently, various installation scripts are required, per platform, which already assume a set of tools and configuration about the users environment (PowerShell/pwsh, bash/sh, etc.).