Create "empty" Microsoft.NETCore.App package to support a 3.0 workaround

[dagood]

To work around not getting some NuGet features that we won't get in time for 3.0, we need to provide a mostly empty Microsoft.NETCore.App package for the SDK to implement some fixes.

Proposal (thanks for this @dsplaisted!):

• Rename the existing Microsoft.NETCore.App package to something like Microsoft.NETCore.App.Internal or Microsoft.NETCore.App.Insertion
• Create a new Microsoft.NETCore.App package which has no assets, and only has a dependency on Microsoft.NETCore.Platforms

Issues this will help with:

• Package downgrades when version 1.x of Microsoft.NETCore.App is in the dependency graph: Restore fails if netstandard1.x package reference is present sdk#3044
• Package downgrades for Microsoft.NETCore.Platforms
• Platforms package showing up with warning icon in VS solution

Once Runtime Pack work is complete and those are used instead of Microsoft.NETCore.App, we can stop producing Microsoft.NETCore.App.Internal.

/cc @nguerrera

[nguerrera]

You might need to do runtime packs first so that the current old targeting packs don't become .Internal and break things

[dagood]

I don't think that will be a problem based on how the infra is set up, but I'll keep the order flexible if something pops up.

[dagood]

I normally run with -skiptests=true because they've been irrelevant to my work, but I tried running my changes for this workaround through CI and the tests are trashed. The projects being restored are like this:

https://github.com/dotnet/core-setup/blob/a458284434f18ad8acbbf867d7338d66e021ad3a/src/test/Assets/TestProjects/PortableApp/PortableApp.csproj#L3-L7

There are generic "the world is ending" compilation errors like:

Program.cs(9,13): error CS0103: The name 'Console' does not exist in the current context

but more specifically the runtime packages are missing:

C:\git\core-setup\bin\tests\win-x64.Release\1\StandaloneAppWithSubDirs\StandaloneAppWithSubDirs.csproj : error : NETSDK1056: Project is targeting runtime 'win-x64' but did not resolve any runtime-specific packages. This runtime may not be supported by the target framework.

I'm not really familiar with the tests but I think this is to be expected because Core-Setup is on SDK 2.1.401 so the Microsoft.NETCore.App packages still matter quite a bit.

The first thing that comes to mind is creating:

• Old-style Microsoft.NETCore.App and runtime packages for tests, which we don't publish.
• The workaround Microsoft.NETCore.App for downstream, which we do publish.
• The Microsoft.NETCore.App.Insertion and runtime packages for legacy downstream, transport packages.

I haven't looked deeper into the problem yet though, like if it would be reasonable to add PackageReferences to all the test projects to use the Insertion package explicitly rather than relying on the implicit runtime.

---

@dsplaisted @nguerrera @ericstj @johnbeisner any thoughts?
To check my sanity, these kinds of error are expected in this situation, right?

[dagood]

I haven't looked deeper into the problem yet though, like if it would be reasonable to add PackageReferences to all the test projects to use the Insertion package explicitly rather than relying on the implicit runtime.

This is actually easy to do non-intrusively... I can add this in the mix to use the insertion package when necessary:

  <ItemGroup Condition="'$(TargetFramework)' == 'netcoreapp$(NETCoreAppMaximumVersion)'">
    <PackageReference Include="Microsoft.NETCore.App.Insertion" Version="$(MNAVersion)" />
  </ItemGroup>

One test still fails:

<UnitTestResult executionId="ab0d5538-a214-4032-81c7-e17465d0d52a" testId="9792fd96-52fa-4023-bc01-3316d83a33ea" testName="Microsoft.DotNet.CoreSetup.Test.HostActivation.PortableAppActivation.Muxer_Activation_With_Templated_AdditionalProbingPath_Succeeds" computerName="DAGOOD-2" duration="00:00:01.1810000" startTime="2019-04-16T17:17:25.6977765-05:00" endTime="2019-04-16T17:17:25.6977823-05:00" testType="13cdc9d9-ddb5-4fa4-a97d-d965ccfc6d4b" outcome="Failed" testListId="8c84fa94-04c1-424b-9868-57a2d4851a1d" relativeResultsDirectory="ab0d5538-a214-4032-81c7-e17465d0d52a">
            <Output>
                <ErrorInfo>
                    <Message>Microsoft.DotNet.Cli.Build.Framework.BuildFailureException : Command failed with exit code 1: C:\git\core-setup\Tools/dotnetcli/dotnet.exe store --runtime win-x64 --framework netcoreapp3.0 --manifest C:\git\core-setup\src\test\Assets\TestProjects\PortableApp\PortableApp.csproj -o C:\git\core-setup\bin\tests\win-x64.Release\4\PortableApp\store /p:MNAVersion=3.0.0-preview5-27616-0 /p:NETCoreAppFramework=netcoreapp3.0 /p:OutputType=Library&#xD;
Standard Output:&#xD;
Microsoft (R) Build Engine version 15.8.166+gd4e8d81a88 for .NET Core&#xD;
Copyright (C) Microsoft Corporation. All rights reserved.&#xD;
&#xD;
  Restoring packages for C:\git\core-setup\src\test\Assets\TestProjects\PortableApp\PortableApp.csproj...&#xD;
  Generating MSBuild file C:\Users\dagood\AppData\Local\Temp\il2uju1l.qut\Optimize\PortableApp.csproj.nuget.g.props.&#xD;
  Generating MSBuild file C:\Users\dagood\AppData\Local\Temp\il2uju1l.qut\Optimize\PortableApp.csproj.nuget.g.targets.&#xD;
  Restore completed in 118.28 ms for C:\git\core-setup\src\test\Assets\TestProjects\PortableApp\PortableApp.csproj.&#xD;
C:\git\core-setup\Tools\dotnetcli\sdk\2.1.401\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.CrossGen.targets(48,5): error NETSDK1016: Unable to find resolved path for 'coreclr'. [C:\git\core-setup\src\test\Assets\TestProjects\PortableApp\PortableApp.csproj]&#xD;
&#xD;
</Message>
                    <StackTrace>   at Microsoft.DotNet.Cli.Build.Framework.CommandResult.EnsureSuccessful(Boolean suppressOutput) in C:\git\core-setup\src\test\TestUtils\CommandResult.cs:line 47&#xD;
   at Microsoft.DotNet.CoreSetup.Test.TestProjectFixture.StoreProject(DotNetCli dotnet, String runtime, String framework, String manifest, String outputDirectory) in C:\git\core-setup\src\test\TestUtils\TestProjectFixture.cs:line 228&#xD;
   at Microsoft.DotNet.CoreSetup.Test.HostActivation.PortableAppActivation.CreateAStore(TestProjectFixture testProjectFixture) in C:\git\core-setup\src\test\HostActivationTests\PortableAppActivation.cs:line 433&#xD;
   at Microsoft.DotNet.CoreSetup.Test.HostActivation.PortableAppActivation.Muxer_Activation_With_Templated_AdditionalProbingPath_Succeeds() in C:\git\core-setup\src\test\HostActivationTests\PortableAppActivation.cs:line 131</StackTrace>
                </ErrorInfo>
            </Output>
        </UnitTestResult>

C:\Users\dagood\AppData\Local\Temp\il2uju1l.qut\Optimize\project.assets.json shows that the insertion package wasn't added, so there's probably just something I'm doing wrong and this could work fine. Still looking at it. Input appreciated.

/cc @vitek-karas @swaroop-sridhar (in case you have suggestions on how you expect the tests to evolve in 3.0)

[vitek-karas]

There are 2 sets of assemblies we use to run the tests.

• The test assemblies themselves which I think are simply built using whatever CLI is available in the repo - they don't directly exercise the product in any way - they're mostly just drivers. These are the XUnit assemblies.
• Mostly test applications (but also some libs) which we use to verify product behavior by actually running them on the built product. These need to be built against the targeting/runtime packs produced by the build as we'll be using the NETCoreApp produced by the build to actually run them.

I don't see us changing this structure for 3.0 in any interesting way. We are trying to limit the number of tests which will actually end up truly running the managed code using the produced NETCoreApp, but we can't completely remove those (they are very valuable as end to end tests).

[dagood]

Thanks for the input. The test applications are what's broken, so I'll just do whatever looks the most straightforward to get them running again.