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

Avoid having runtime specific assets when they aren't necessary. #21796

Closed
weshaggard opened this issue May 18, 2017 · 2 comments
Closed

Avoid having runtime specific assets when they aren't necessary. #21796

weshaggard opened this issue May 18, 2017 · 2 comments
Assignees
Milestone

Comments

@weshaggard
Copy link
Member

Due to an issue in nuget which will hopefully be address with NuGet/Home#5192 some of our packages end up with the wrong asset being selected when we have both runtime and lib assets in the package. For some of our packages that isn't necessary.

Example: System.Security.Permissions has a runtime\net461 asset and a lib\netstandard2.0 asset and when a netcoreapp2.0 project has a fallback of net461 we will prefer the net461 asset over the netstandard2.0 asset which will not work on netcoreapp2.0. See https://github.com/dotnet/corefx/issues/19929.

We should do an audit of other packages in this situation to avoid it.

@ericstj
Copy link
Member

ericstj commented May 18, 2017

As we discussed the duplicated asset is completely unnecessary. This situation was less likely in 1.0 due to the way we had factored projects but became more likely in 2.x because the config system made it easy.

@ericstj
Copy link
Member

ericstj commented May 19, 2017

Reopen for rel/2.0

@ericstj ericstj closed this as completed May 22, 2017
@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the 2.0.0 milestone Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 23, 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