Introduce `NUGET_NETFX_PLUGIN_PATHS` and `NUGET_NETCORE_PLUGIN_PATHS` to support configuration of both at same time
zjrunner opened this issue · comments
NUGET_PLUGIN_PATHS can't be configured statically, to work for both nuget.exe and dotnet. If you add paths for the .exe and .dll credential providers to handle both cases, nuget fails trying to execute a dll and dotnet fails trying to execute the full framework .exe.
Details about Problem
NuGet product used (NuGet.exe | VS UI | Package Manager Console | dotnet.exe):
nuget.exe, dotnet.exe
NuGet version (x.x.x.xxx):
5.0.0.5856
dotnet.exe --version (if appropriate):
2.2.300
VS version (if appropriate):
OS version (i.e. win10 v1607 (14393.321)):
win10 v1903
Worked before? If so, with which NuGet version:
no
Detailed repro steps so we can see the same problem
set nuget_plugin_paths=d:\tools\credprovider\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll;d:\tools\credprovider\plugins\netfx\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe- (fails)
nuget.exe install newtonsoft.json - (fails)
dotnet new web & dotnet add package newtonsoft.json
Nikolche-Proposed fix for this?
Currently this is broken by design.
Here's an idea.
- Read env variable and process values. Consider *.exe if netfx, consider .NET Core if dll. Use for both if there's no extension.
https://github.com/NuGet/NuGet.Client/blob/dev/src/NuGet.Core/NuGet.Protocol/Plugins/PluginDiscoverer.cs
The convention based discovery already establish that .exe and .dll are required in the name for netfx and netcore respectively.
The one scenario we need to account for is overriding and disabling all plugins.
Currently "" overrides everything and says do not use any plugins for my nuget invocations.
Would
nuget_plugin_paths=d:\tools\credprovider\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll"
suggest that no plugins should be used for netfx, or just select the default?
Is that a scenario we even care about specific for one framework, but default for other? Do we define a special moniker?
The fix is not complex, we just need to remember to run through these scenarios.
Maybe we can learn from other tooling?
That sounds like the fix I had assigned to the issue earlier, so we're in alignment. There is a test that uses ";" to force skipping the fallback, and I originally had an empty filtered list fallback to the core discovery but founds several cases where it would make it harder to detect typo configuration. I decided to keep it as close to the current behavior w.r.t. full-override behavior, but do the simplest filter for now.