Generate a nuget package which contains the runtime pack for Microsoft.AspNetCore.App

[natemcmaster]

Part of #6501

Changes:

• Create a new package - Microsoft.AspNetCore.App.Runtime.${rid} - which contains crossgen-ed versions of shared framework assemblies.
• Add a task which can generate the .deps.json file for the shared framework. Unlike the existing task we have, this does not rely on consuming a .deps.json file generated by first running a restore on packages.

TODO (in a separate PR)

• Update the layout of this package to match what the SDK will expect to use
• Stop producing the "runtime.*.Microsoft.AspNetCore.App" package. This will be retired in favor of the package added in this PR.
• Where do platform manifests and package conflict data go?

cref dotnet/designs#50

cc @dsplaisted @nguerrera @dagood

[pakrym]

Add a task which can generate the .deps.json file for the shared framework. Unlike the existing task we have, this does not rely on consuming a .deps.json file generated by first running a restore on packages.

Why?

[natemcmaster]

Why?

The SDK's .deps.json generation task requires a project.assets.json file, and it doesn't handle ProjectReference or native assets. I wrote the task to workaround these limitations. This will mean we can stop producing packages at all for assemblies that are shared framework only, like Mvc.dll.

[dsplaisted]

@natemcmaster If you want to put a locally-built copy of these packages on a share somewhere, I can test consuming them in the SDK.

[natemcmaster]

Build failure in PR:

LINK : fatal error LNK1104: cannot open file 'Release\tracelog.obj' [F:\vsagent\2\s\src\Servers\IIS\AspNetCoreModuleV2\IISLib\IISLib.vcxproj]

https://dev.azure.com/dnceng/public/_build/results?buildId=93376&view=logs&jobId=f31c9f97-4411-58e7-49ac-fc73f645e6b6&taskId=6eab48b9-b4ce-58d4-7c0f-2d2ef2bbc0bd&lineStart=3479&lineEnd=3479&colStart=1&colEnd=142

Any ideas @jkotalik @pakrym? Is this something you see often? I periodically see issues like this with vcxproj. I think it's a race condition because retrying the build often makes it go away.

[pakrym]

I haven't seen this failure before but it's very likely a race because Release\tracelog.obj is not under platform specific directory and we are building two platforms in parallel.

[natemcmaster]

More flaky C++ build failures:

f:\vsagent\2\s\src\servers\iis\aspnetcoremodulev2\commonlib\stdafx.cpp : fatal error C1041: cannot open program database 'F:\vsagent\2\s\src\Servers\IIS\AspNetCoreModuleV2\CommonLib\Release\CommonLib.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS [F:\vsagent\2\s\src\Servers\IIS\AspNetCoreModuleV2\CommonLib\CommonLib.vcxproj]
FileTracker : error FTK1011: could not create the new file tracking log file: F:\vsagent\2\s\src\Servers\IIS\AspNetCoreModuleV2\CommonLib\Release\CommonLib.tlog\CL.write.1.tlog. The file exists. [F:\vsagent\2\s\src\Servers\IIS\AspNetCoreModuleV2\CommonLib\CommonLib.vcxproj]

[pakrym]

I think you are double building in this PR. It's slightly flaky but not this much.

[natemcmaster]

I don't think it's a double build of the same architecture. The binlogs show MSBuild doing the right thing and de-duplicates the build request. The errors show problems with files shared between x86 and x64 builds.

[natemcmaster]

Everything passed on retry except Helix. I'm looking into it more...

[natemcmaster]

It looks like Helix problems were unrelated to this change, but surfaced as a result of adding a new project. I've made some tweaks to the ways Helix builds add a dependency to xunit.runner.console (cc @HaoK )

[natemcmaster]

CI checks passed, and after running build 5 times, I haven't been able to get a repro of the flaky CI problems. If we run into this again, we can revert and investigate.

I opened a bug for the flaky Helix test failure, but it appears unrelated to this change, so merging now.