Update CoreFX, CoreCLR dependencies in pkg/projects to latest

[dagood]

This is a one-off run of VersionTools on the project.jsons in pkg/projects to update everything to the latest CoreFX and CoreCLR builds.

@brianrob @weshaggard
/cc @gkhanna79

[gkhanna79]

I see failures like the following:

Unhandled Exception: System.TypeLoadException: Could not load type 'System.IO.Stream' from assembly 'System.IO, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.

@weshaggard Is this due to types being refactored/relocated?

[weshaggard]

Yes something seems broken there, but I wouldn't expect to have any version of System.IO.dll that doesn't have Stream or a type-forward for Stream. I will pull this change locally and try and figure out what is wrong.

cc @ericstj

[dagood]

There are also:

Unhandled Exception: System.TypeLoadException: Could not load type 'System.IO.TextWriter' from assembly 'System.IO, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

TextWriter was moved in dotnet/corefx#12480, but I can't find anything about moving Stream. (I don't know for sure if the move is related.)

[mellinoe]

I was trying something similar and hit the same problem with TextWriter not being defined in System.IO. I think something might be broken in the latest packages.

[weshaggard]

I don't believe there is anything necessarily broken with our packages but their is some issues with the meta-package which I'm looking for a way to address. We may also need to update the CLI we are using to get a nuget update for the netstandard1.7 -> netcoreapp1.1 mapping.

The core of the problem is that when you update the CoreCLR package and you restore for netcoreapp1.0 you get the latest S.P.CoreLib which is no longer compatible with the other netcoreapp1.0 libraries. In particular System.IO. We are essentially hitting https://github.com/dotnet/coreclr/issues/7607.

@jkotas @gkhanna79 we are likely going to want to update the CoreCLR packages so that it correctly ships S.P.Corelib/mscorlib that works for netcoreapp1.0 apps in another folder.

[ericstj]

@jkotas @gkhanna79 we are likely going to want to update the CoreCLR packages so that it correctly ships S.P.Corelib/mscorlib that works for netcoreapp1.0 apps in another folder.

Alternatively we could constrain the coreclr package reference to the 1.0 version for netcoreapp1.0 and use the 1.1 version for netcoreapp1.1. That's the thing that's bringing in the lineup and eventually the runtime mscorlib/s.p.c.

[weshaggard]

Alternatively we could constrain the coreclr package reference to the 1.0 version for netcoreapp1.0 and use the 1.1 version for netcoreapp1.1. That's the thing that's bringing in the lineup and eventually the runtime mscorlib/s.p.c.

Yes that is what I'm working on right now as the fix. However we still have the question of whether or not the runtime package itself should be backwards compatible.

[gkhanna79]

you restore for netcoreapp1.0 you get the latest S.P.CoreLib which is no longer compatible with the other netcoreapp1.0 libraries.

we still have the question of whether or not the runtime package itself should be backwards compatible

My mental model is that master branch of every repo is forward looking and is expected to undergo such changes as are happening right now and even breaking in future and map to a different netcoreapp. If something needs an older netcoreapp, then one of the following should happen:

1. They could either restore the corresponding supporting dependencies OR
2. They target the new netcoreapp version and restore supporting dependencies.

Is there a concern with such an approach? And supporting multiple netcoreapp versions in a single package should not be unique to the runtime paclage (unless I am missing something).

[weshaggard]

Is there a concern with such an approach? And supporting multiple netcoreapp versions in a single package should not be unique to the runtime paclage (unless I am missing something).

It isn't unique to just the runtime package. The corefx packages already handle this by having new things in either netcoreapp1.1 or a higher netstandard folder. The key differences is you can always update to a latest corefx package and still work on the older platforms because you will just get the older version from the latest package.

Forcing folks to remain with an older version of your package might be fine for the runtime package because we don't expect people to directly reference it but if there are any cases were multiple other packages in the graph reference multiple versions of the runtime package the highest version will be the one chosen and that could break things given it isn't backwards compatible.

[weshaggard]

Replaced by #462.

[gkhanna79]

if there are any cases were multiple other packages in the graph reference multiple versions of the runtime package

Runtime package is an implementation detail of an appmodel package (like UWP or M.N.App) and available via it - and I am not sure if there is a valid scenario where we can expect folks to explicitly reference multiple of such packages. And on similar lines, if someone is referencing multiple runtime packages (directly or indirectly via AppModel packages), I would expect them to be on their own and understand why they are doing what they are doing.

Please let me know if I am missing something.