clrcompression package issues

[weshaggard]

Currently there is a Win7 and Win10, the one in Win10 has the appcontainer which causes some issues issues for folks outside of UWP. To help eliminate potential conflicts we should put the Win10 access in the netcore50 folder as that is the only one that is used for UWP.

https://github.com/dotnet/corefx/blob/master/src/Native/pkg/runtime.native.System.IO.Compression/win10/runtime.native.System.IO.Compression.pkgproj#L13

runtimes/lib/netcore50/

On top of that the ARM version of this package has a win7-arm asset which isn't even a valid RID. It would need to be a win8-arm or higher.

We should do some validation on the various scenarios for this package.

cc @mellinoe @ericstj

[mellinoe]

Thanks for filing this, I've been meaning to get around to it.

[ianhays]

Shouldn't the TargetPath be <TargetPath>lib/netcore50>/TargetPath> instead of <TargetPath>runtimes/lib/netcore50</TargetPath>?

On top of that the ARM version of this package has a win7-arm asset which isn't even a valid RID. It would need to be a win8-arm or higher.

This is a result of the weird naming scheme we've adopted where win7=nonappx and win10=appx. I'd really prefer it be something like win/win-appx to make the distinction clear. Is it too late to change that or otherwise make this easier to figure out without reading the comment in the pkgproj?

[ericstj]

Should be runtimes/win10-$(PackagePlatform)/lib/netcore50

The problem with creating an new pivot in the RID graph is that its exponential and requires a change in VS to pick it up. For now we can use netcore50 to represent appx.

[weshaggard]

@ianhays Unless I missed it it doesn't look like your PR dotnet/corefx#7840 fixed the ARM issue. We still need to address that.

[ianhays]

No you're right, it did not change the RID for ARM. I'll push a quick fix for that.

[ericstj]

I think this is still broken. If I use win10-x64 I'll get the runtime.win10-x64.runtime.native.System.IO.Compression package which only contains the netcore50 implementation. If you're going to keep the packages split on RID this way then you'll need to also include the implementation other frameworks.

[ericstj]

You may need this nuget fix in order to do this correctly and get it to work with CLI: NuGet/Home#2782

[ianhays]

To clarify the context here, our current packaging state after the previous PRs for this issue is like this:

• win7
  • non-appx under runtimes/win7-$(PackagePlatform)/native
• win8
  • non-appx under runtimes/win8-$(PackagePlatform)/native
• win10
  • appx under runtimes/win10-$(PackagePlatform)/lib/netcore50

The remaining issue is that people targeting win10 do not get a non-appx version of clrcompression. They can only actually get a clrcompression if they're targeting netcore50 and then they better be wanting APPX (related: https://github.com/dotnet/cli/issues/2912).

The solution is to include the non-appx clrcompression used for win7/win8 into win10. My immediate thought is that we should be able to just put it under runtimes/win10-$(PackagePlatform)/native

You may need this nuget fix in order to do this correctly and get it to work with CLI: NuGet/Home#2782

I'm not sure how that NuGet issue blocks us from including the non-appx clrcompression into the win10 package. I'm guessing there is some sort of issue on the NuGet side of things with that? Or is the issue that having two clrcompressions (one under lib/netcore50 and one under native) would confuse the package restoration?

[ericstj]

My immediate thought is that we should be able to just put it under runtimes/win10-$(PackagePlatform)/native

If you did that, then both the runtimes/win10-$(PackagePlatform)/lib/netcore50 and runtimes/win10-$(PackagePlatform)/native clrcompression.dll's would apply. We could decide to use runtimes/win10-$(PackagePlatform)/lib/netstandard* and runtimes/win10-$(PackagePlatform)/lib/netcore50 which would do the right thing in MSBuild, but not for CLI since the host needs to understand the difference between lib and native.

That's why you need the nuget fix. It lets us represent both dlls as native while also constraining the UWP one by netcore50.

[ianhays]

Gotcha, thanks for the rundown. I wasn't sure if lib would take precedence over native in restoration and one would replace the other or if the restoration would just fail. Either way being able to put them all under native/TXM would be cleaner.

I'll prep a fix so we can submit it right when NuGet/Home#2782 merges.