-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
PackageValidation task should not filter package assets. #18165
Comments
I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label. |
We should remove that filtering, and then refactor the code so that if the ref or runtime asset picked for a specific framework is not a .dll (like in the case of a |
dotnet/aspnetcore#744 (comment) has more details around what a placeholder file means. |
Fixes dotnet#18165 Instead of manually filtering package assets, let NuGet calculate the runtime and compile time assets and handle placeholder files which are returned by NuGet.
Fixes dotnet#18165 Instead of manually filtering package assets, let NuGet calculate the runtime and compile time assets and handle placeholder files which are returned by NuGet.
Fixes dotnet#18165 Instead of manually filtering package assets, let NuGet calculate the runtime and compile time assets and handle placeholder files which are returned by NuGet.
cc: @Anipik @safern @ericstj
While testing package validation I noticed that apparently we are filtering the assets that we consider when parsing a package here:
sdk/src/Compatibility/Microsoft.DotNet.PackageValidation/NupkgParser.cs
Line 45 in 2347c72
The problem with this, is that we will only consider those filtered files when calculating the best compile and runtime asset to verify APICompat for, but that is not always accurate, as a package could have an asset like
lib/net461/_._
which should win as a runtime asset over alib/netstandard2.0/Foo.dll
when evaluating for net461, and that is not happening today. This is important as the previously mentioned example, means that effectively I would be intentionally dropping support for net461, but package validation won't catch it as it would evaluate APICompat against the netstandard2.0 asset.The text was updated successfully, but these errors were encountered: