1. Use PackageOutputPath variable exclusively everywhere instead of our own name for the same path.
2. Split nuget packages and installer assets into separate paths - packages and assets.
* Enable building debian installers for Dotnet Runtime Meta packages ( Pre-requisite system packages )
* Updated per PR feedbacks
* Refactor LibIcuPackage compute step
Currently, when building non-portable on a win10 machine, core-setup restores and produces `win7` RID assets. This causes problems in source-build since corefx produces `win10` assets on the same machine. Thus, core-setup can't use the corefx assets because win10 is not compatible with win7.
In fixing this, I refactored the way RIDs are handled during the build. We have 3 main RID usages:
* What is the RID of the current machine? $(HostMachineRid)
* What is the RID of the toolset we are using to build? core-setup doesn't have this scenario yet, but corefx calls this $(ToolRuntimeRID)
* What is the RID that the current build is producing outputs for? $(OutputRid)
Set DisableImplicitNuGetFallbackFolder=false to ensure we never use the NuGet fallback folder that comes with the SDK.
Enable SDK-based projects to import the root dir.props file. This spawned a few one-off changes since things like the BaseIntermediateOutputPath is now under RepoRoot\Bin and TreatWarningsAsErrors=true.
VersionSuffix is getting set before $(BuildNumberMajor) and $(BuildNumberMinor) are being set. When creating the DependencyModel nupkg, it is getting a bad version on its p2p reference to PlatformAbstractions.
The fix is to ensure VersionSuffix is defined correctly in the projects themselves - after the obj\BuildVersion.props file is created.
Workaround https://github.com/NuGet/Home/issues/4337
Set DisableImplicitNuGetFallbackFolder=false to ensure we never use the NuGet fallback folder that comes with the SDK.
Enable SDK-based projects to import the root dir.props file. This spawned a few one-off changes since things like the BaseIntermediateOutputPath is now under RepoRoot\Bin and TreatWarningsAsErrors=true.
* Update Microsoft.Net.CoreRuntime.targets to those shipped in latest VS
* Generate Microsoft.Net.CoreRuntime.settings.targets from template during build
* Successfully build and sign Microsoft.Net.CoreRuntimeTask.dll
* Copy Microsoft.Cci to the output of Microsoft.Build.Net.CoreRuntimeTask.dll and include Microsoft.Cci.dll in identity package for Microsoft.Net.UWPCoreRuntimeSdk
* Correctly generate .props/.targets files for each RID-specific package of Microsoft.Net.UWPCoreRuntimeSdk to provide information about the Appx packages. Change Microsoft.Net.CoreRuntime.targets and WireUpCoreRuntime appropriately.
* Make Microsoft.Net.CoreRuntime.targets consume x86 CopyWin32Resources.exe from the native x86 runtime package
* Rearrange source of Microsoft.Net.UWPCoreRuntimeSdk. Add Microsoft.Net.UWPCoreRuntimeSdk.props to point to Microsoft.Net.CoreRuntime targets files in NuGet package
* Make fixes to complete VS integration
* Address PR feedback. Change uap moniker to use property $(UAPvNextTFM)
* Add all files except for Microsoft.Build.Net.CoreRuntimeTask.dll which Microsoft.Net.CoreRuntime.targets will rely upon when implemented
* Move targets files into a subdirectory that better maps to final NuGet package contents
* Update Microsoft.Net.UWPCoreRuntimeSdk package so the identity package carries the necessary .props/.targets files for VS and the RID-specific packages carry the binaries and appx package. Right now the VS files are not complete, but merely mocked up to achieve right structure
* Clean up some unnecessary changes
* Fix build ordering issue
Work-around the packaging for UWPCoreRuntimeSdk requiring the appx from
the Microsoft.NET.CoreRuntime sister project by serializing the
packaging projects. This takes advantage of the OS API returning
directory contents in lexicographical order - alternatively we could
manually enumerate the list of projects.
* CR Feedback
Factor path to Microsoft.Net.CoreRuntime.2.1.appx into props so both uses refer to the same thing
Fix up unix build failures
* Make project list explicit
VersionSuffix is getting set before $(BuildNumberMajor) and $(BuildNumberMinor) are being set. When creating the DependencyModel nupkg, it is getting a bad version on its p2p reference to PlatformAbstractions.
The fix is to ensure VersionSuffix is defined correctly in the projects themselves - after the obj\BuildVersion.props file is created.
Workaround https://github.com/NuGet/Home/issues/4337