-
Notifications
You must be signed in to change notification settings - Fork 691
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
Filter framework-mismatched assemblies from NUGET_PLUGIN_PATHS #2859
Conversation
Prior to this, if you configured both a netcore and a netfx plugin to handle both nuget and dotnet, both would fail. One would fail on the dll, the other on the exe. nuget_plugin_paths=d:\tools\credprovider\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll;d:\tools\credprovider\plugins\netfx\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe This change does a naive filter based on existing discovery models for convention-based plugin loading.
I just now noticed this. :) |
Not sure what you mean by this? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm ok with this change.
We need to document it.
If you define a plugin for .NET Framework, you need to define one for .NET Core as well.
The environment variables are a special scenario.
We are also kind of changing the behavior where we require plugins to be exe or dll, but I don't imagine that's a big deal, as the convention based discovery already does that.
Again, we can document that.
Can you please take a look at this so we can merge it to 5.2? @zivkan @heng-liu @dominoFire @donnie-msft Any feedback is appreciated. |
dotnet3 sdk now will create an exe by default for netcoreapp3 projects. (tested with p5 on my machine) |
Another option that we discsussed would be multiple environment variables. One of netfx and netcore each. Those variables would take preference over the old one which would apply to both. |
Sorry for the delay @zjrunner I will have a write-up and a PR later today. |
Closing in favor of #2986. |
Prior to this, if you configured both a netcore and a netfx plugin to handle both nuget and dotnet,
both would fail. One would fail on the dll, the other on the exe.
nuget_plugin_paths=d:\tools\credprovider\plugins\netcore\CredentialProvider.Microsoft\CredentialProvider.Microsoft.dll;d:\tools\credprovider\plugins\netfx\CredentialProvider.Microsoft\CredentialProvider.Microsoft.exe
This change does a naive filter based on existing discovery models for convention-based plugin loading.
Bug
Fixes: NuGet/Home#8151
Regression: No
Fix
Use the same logic as the convention based plugin discovery to filter the paths in NUGET_PLUGIN_PATHS. Do not fallback to the baseline discovery if all paths are filtered out to hold a line on typo discovery. This does exclude self-contained dotnet exes from plugin_paths, but since they weren't possible in discovery anyway this feels like an ok compromise.
Testing/Validation
Tests Added: Yes
Validation:
verified failure of nuget 5.0.0 as in the linked issue, verified failing unit test as created, fixed the code, verified passing unit tests and passing commandline of built-nuget.exe