-
Notifications
You must be signed in to change notification settings - Fork 44
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
Support netcoreapp1.1 tfm #121
Comments
|
I'm not sure how relevant "netcoreapp1.1" is anymore, but there may be related work for .NET Core 2.0. @Eilon do we expected ASP.NET Core 2.0 packages to be compatible with the netcoreapp1.0 TFM? i.e. we are keeping netstandard1.3 where possible. Will packages that upgrade to netstandard2.0 be required to keep a TFM that is compatible with netcoreapp1.0? |
Actually, can you remind me what this bug is about? Is it about our build tools run on, about what the tools work with and/or produce, or something else? |
The bug was that package cache generation uses .NET Core 1.0, but the dependency graph for .NET Core 1.1 is different, so cross gen uses the wrong references. Also, our coherence check only ensures that packages are compatible with .NET Framework 4.5.1 or .NET Core 1.0. I know this is changing, but not sure what the new runtime version prerequisites will be. |
@JunTaoLuo @DamianEdwards - with the new package cache/store feature, presumably this issue doesn't apply anymore. However, for our 2.0 wave of bits, of course the new package cache will work when running on .NET Core App 2.0, but do we expect it to work on 1.0/1.1? |
The package cache is built for netcoreapp2.0 and it's not expected to work on 1.0/1.1. However, we can try building the package cache for netcoreapp1.1 and 1.0. |
@DamianEdwards is that a thing? Do we need that? |
I don't really understand this issue. Can we sync in person? |
Spoke offline, this is not a supported scenario. |
The dependency graph of apps targeting netcoreapp1.1 will be slightly different from those using netcoreapp1.0. Build tools should account for this new TFM.
I found two instances where this might apply, and we should investigate if netcoreapp1.1 makes a difference:
SplitPackages only check compatibility with netcoreapp1.0.
DependencyPackager only crossgen's for netcoreapp1.0.
The text was updated successfully, but these errors were encountered: