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

Support netcoreapp1.1 tfm #121

Closed
natemcmaster opened this issue Nov 10, 2016 · 9 comments
Closed

Support netcoreapp1.1 tfm #121

natemcmaster opened this issue Nov 10, 2016 · 9 comments

Comments

@natemcmaster
Copy link
Contributor

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.

@Eilon Eilon added this to the 1.2.0 milestone Nov 23, 2016
@natemcmaster
Copy link
Contributor Author

@natemcmaster
Copy link
Contributor Author

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?

cc @DamianEdwards

@Eilon
Copy link
Member

Eilon commented Mar 18, 2017

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?

@natemcmaster
Copy link
Contributor Author

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.

@Eilon
Copy link
Member

Eilon commented Apr 6, 2017

@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?

@JunTaoLuo
Copy link
Contributor

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.

@Eilon
Copy link
Member

Eilon commented Apr 6, 2017

@DamianEdwards is that a thing? Do we need that?

@DamianEdwards
Copy link
Member

I don't really understand this issue. Can we sync in person?

@JunTaoLuo
Copy link
Contributor

Spoke offline, this is not a supported scenario.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants