This causes three pkg files to be produced:
* A component pkg for the shared framework.
* A component pkg for the shared host.
* A product archive which includes the above two components.
The product archive also needs a distribution.xml file which contains
metadata about the package (name, title, images, etc.).
The installer for the "SDK" itself is still using logic implemented in
package-osx.sh. We should move this logic into the build target as well,
but we may want to wait until the CLI is using the shared framework to do so.
- Use Crossgen's Ready To Run mode on all of the managed assemblies
that make up the shared framework.
- Upgrade the version of the shared framework to match what is used
in the rest of CLI (see the comment in SharedFrameworkTargets.cs to
understand why this is needed).
- Remove the IL mscorlib.dll image, since the Crossgen'd image is
already published.
Fixesdotnet/corefx#6753
Ideally in the project.json for the shared host we would just list the
actual package that holds the shared host, instead of all of
NetStandard.Library, but doing some leads to compliation errors, since
publish wants to include a compile step that has a generated
AssemblyAttributes file which references types like System.String.
- Add libssl-dev dependency to DockerFile, because the package upgrade test still depend on this. It can be removed once a newer package without libssl-dev dependency is uploaded.
- Check pre-reqs in the package script.
dotnet-build will produce a deps file for portable builds, and will now
create "runnable" outputs for RID-less targets
the outputs won't actually be runnable today because we need corehost
changes and to generate a deps.json file for corehost to use.
Update .exe's project.json Target Framework from dnxcore50 to netstandardapp1.5.
Update .dll's project.json Target Framework from dnxcore50 to netstandard1.3.
Adding workaround for DataContractSerialization to src\dotnet\project.json to fix crossgen issue.
Build 23901 has a dependency issue that doesn't allow the runtime.any.System.Private.DataContractSerialization
package to be restored. When we move to a new build of CoreFX we should take this workaround out.
- Changes to build scripts to produce Winx86 build artifacts like
zip/installer.
- Change to run Nuget-xplat in the same process as dotnet.exe instead of
spinning up a new 'corerun' process.