Reduced native nuspec (removed ch.exe from nuspec)

[dilijev]

(Mainly discussion -- don't merge yet.)

See #85 #2266 #2435

Advantage of this change: package size is smaller, although not by a huge amount. Uncompressed size difference is greater, but again, by a relatively small percentage of the remaining size.

Package sizes:

Microsoft.ChakraCore.1.4.1.nupkg -- 6.32 MB (unpacked: 15.8 MB)
Microsoft.ChakraCore.vc140.1.4.1.nupkg -- 98.6 MB (unpacked: 405 MB)
Microsoft.ChakraCore.vc140-reduced.1.4.1.nupkg -- 93.0 MB (unpacked: 376 MB)

Disadvantage of this change: for people who are interested in trying out the features by using ch.exe, they would have to build ch.exe themselves instead of having it already-available in the package. NuGet packages are our primary release distribution mechanism (the other being the files attached to GitHub releases) and they are the only release mechanism for preview builds, so this change would reduce the accessibility of ch.exe to developers who want to quickly explore new features or other changes between builds.

---

In summary, I'm personally leaning against this change as-is. I think another alternative can be found to solve the scenario of needing smaller package sizes.

For instance, we could add definitions for flavor-specific packages for Native in addition to .NET which only include the files necessary for development (i.e. not ch.exe). This also allows a developer who is only interested in targeting a specific architecture (for a low-memory device like an embedded system) to download a package containing just the files they need.

The disadvantage of such a proposal is that it represents yet more packages to maintain and publish on our end.

A compromise is to provide nuspec files for these flavor-specific configurations as well as reduced-size-for-all-flavors (this PR as a separate file) which would allow developers that need those specific configurations to repackage our nupkg for their needs, or easily build their own.

[dilijev]

For review and discussion for a future iteration. Not a priority to merge at this time.
/cc @matthargett @pre10der89 @boingoing

[am11]

@dilijev, regarding the slim, trimmed down packages; I am working on similar packaging story for a .NET project which has native depenedencies. It is possible to spin up an <Exec> command in post install targets (Microsoft.ChakraCore.vc140.targets), which compiles certain project at install time (e.g. ch.exe):

<PropertyGroup>
  <PrepareForRunDependsOn>
    $(PrepareForRunDependsOn);
    CompileFromSource
  </PrepareForRunDependsOn>
</PropertyGroup>

<Target Name="CompileFromSource">
  <!-- cross-platform -->
  <!-- cmake, cl, clang, gcc, msbuild or any command would work -->
  <Exec Command="cmake . --build"
        ContinueOnError="false"
        LogStandardErrorAsError="true"  />

  <!-- or MSBuild / vcxproj specific -->
  <!-- Windows only -->
  <MSBuild BuildInParallel="true"
           Condition=" '$(OS)' == 'Windows_NT' "
           Projects="..\bin\ch\ch.vcxproj"
           Properties="Configuration=$(Configuration)" />
</Target>

It is also possible to download the specific package in post install <Exec> task, matching the {OS,Version,Arch} matrix as an option; from Azure Blob, GitHub Release assets (for example we upload our node.js binding pre-build bins for each platform-arch to releases : https://github.com/sass/node-sass/releases/tag/v4.5.0) or a separate NuGet package containing only binaries. These can be disableable options controller by environment variables e.g. MSCHACKRA_NUGET_BUILD_FROM_SOURCE xor MSCHACKRA_NUGET_DOWNLOAD_PREBUILD_BINS then in .targets file:

<Target Name="CompileFromSource"
        Condition=" $(MSCHACKRA_NUGET_BUILD_FROM_SOURCE) != '' ">
<!-- exec cmake etc. here -->
</Target>

<Target Name="DownloadBinaryForPlatform"
        Condition=" $(MSCHACKRA_NUGET_DOWNLOAD_PREBUILD_BINS) != ''
                    AND
                    $(MSCHACKRA_NUGET_BUILD_FROM_SOURCE) == '' ">
<!-- exec iwr, wget, curl etc. here to download from GitHub Releases or AzBlob etc. -->
</Target>

Fun fact, with dotnet-cli and powershell-for-unix, we can even restore non-dotnet NuGet packages on Unix. So NuGet echosystem is not tied to Windows. :)

[dilijev]

No reason to merge this at this time. Closing.