Skip to content
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

Consider generating PackageConflictOverrides in Microsoft.NETCore.App #3010

Closed
eerhardt opened this issue Jan 19, 2018 · 2 comments
Closed

Comments

@eerhardt
Copy link
Member

The .NET Core SDK implemented a performance enhancement with dotnet/sdk#1805 that allows the conflict resolution tasks to not need to load assemblies in the common case. This works by using a bit of MSBuild metadata called PackageConflictOverrides. These items tell conflict resolution that if it sees a conflict between two NuGet packages, with certain versions, it can immediately resolve the conflict without loading assemblies.

Since Microsoft.NETCore.App and NETStandard.Library 2.0.0 had already shipped, we couldn't add this metadata into the packages.

However, going forward we could consider generating this metadata in new Microsoft.NETCore.App and NETStandard.Library packages, if more package overrides are created and we see a performance degradation again. See dotnet/sdk#1805 (comment).

/cc @ericstj @nguerrera @weshaggard

@dagood
Copy link
Member

dagood commented Jul 24, 2019

However, going forward we could consider generating this metadata in new Microsoft.NETCore.App and NETStandard.Library packages, if more package overrides are created and we see a performance degradation again.

Is this something that can happen in 3.0? Will the move away from "real" NuGet packages to packs make generation not useful?

If the override list won't change at all in the future, maybe we can close this issue.

@eerhardt
Copy link
Member Author

I think this issue can now be closed with dotnet/core-setup#6507. The only thing listed here that wasn't explicitly covered is generating the overridden packages and versions, but I'm not sure that is worth the effort. If we find maintaining that the .txt file manually is too cumbersome, we can re-open this issue, or just create a new one at that time.

@msftgits msftgits transferred this issue from dotnet/core-setup Jan 30, 2020
@msftgits msftgits added this to the Future milestone Jan 30, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 18, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants