Recommendations for improving an existing NuGet packages for .NET projects

Sooner or later, community will create and publish its own NuGet packages. Most likely, when creating new packages, source code of existing packages, that were developed by Microsoft, will be taken as a basis. Existing packages have certain disadvantages, so in this post I will write how it can be fixed and give examples in the form of Git Diffs. Since I am a .NET developer, I will only write about packages oriented on .NET. There are currently five such packages, but only one of them has been published ([Microsoft.ChakraCore](https://www.nuget.org/packages/Microsoft.ChakraCore)).

1. **Abandon using a temporary files to specify package versions.** Currently, the `compiled.nuspec` temporary file is used to dynamically specify a versions of NuGet packages. I suggest using the [built-in feature](https://docs.microsoft.com/en-us/nuget/reference/nuspec#replacement-tokens) of NuGet package manager instead of creating a temporary file. [Pull request](https://github.com/chakra-core/ChakraCore/pull/6566) has already been created to solve this problem.
1. **Do not specify a target framework for package.** Current versions of packages are targeted to .NET Standard 1.0, because of this, they cannot be used in projects oriented on .NET Framework 4.0 or earlier. For packages that contain only native assemblies, do not need to specify a target framework. Most likely, creators of packages initially generated a sample `.nuspec` file from C# project and simply did not clean up it. Therefore, we can [safely remove the target framework](https://github.com/Taritsyn/ChakraCore/commit/e4610e28b61489ff347f94170fc56290aa0fbab6).
1. **Add to MSBuild scripts a ability to deploy an Windows (ARM) assembly for the `AnyCPU` target platform.** In .NET Framework projects with installed the Microsoft.ChakraCore package, during compilation for the `AnyCPU` target platform, MSBuild script creates two subdirectories (`x86` and `x64`) in the `bin\[Debug|Release]` directory, into which it copies the corresponding assemblies. In my opinion, it is worth [implementing a similar functionality for Windows (ARM) assembly](https://github.com/Taritsyn/ChakraCore/commit/4ca4c05d3efaf58d0aeb514cd0f1dde0765bfffa), but perhaps many will not agree with this.
1. **Simplify a conditions in MSBuild scripts.** Currently, MSBuild scripts contain a large number of long conditions that are difficult not only to read, but also to understand. For example, `Exists('packages.config') Or Exists('packages.$(MSBuildProjectName).config')` condition is intended to disable MSBuild scripts in .NET Core projects, because they use a different deployment mechanism. `Exists('project.json') Or Exists('project.$(MSBuildProjectName).json')` condition doesn't make any sense in the context in which it is used. Therefore, should make [refactoring of conditions](https://github.com/Taritsyn/ChakraCore/commit/ee98fffe127c1bff92773158b07a5e4063465b99).
1. **Use a more general RID's.** In the names of runtime directories are used is quite specific [RID](https://docs.microsoft.com/en-us/dotnet/core/rid-catalog)'s: `win7-x86`, `win7-x64` and `win8-arm`. Usage of such identifiers was justified in early releases of .NET Core 1.0, but for now it's better to [switch to using more general identifiers](https://github.com/Taritsyn/ChakraCore/commit/9a39edb69b13dbf2dc2a222d0bdff8b8e0412925): `win-x86`, `win-x64` and `win-arm`.
1. **Use a `license` element.** Currently, when building packages, the following warning is issued: “WARNING: NU5125: The 'licenseUrl' element will be deprecated. Consider using the 'license' element instead.”. To solve this problem, it is necessary to [replace the `licenseUrl` element by the `license` element](https://github.com/Taritsyn/ChakraCore/commit/9e622429bc1141a8d7d96eb56f85a7c3b9bfd786).
1. **Switch to the new symbol package format.** [NuGet.org](https://www.nuget.org/) only accepts the new symbol package format - `.snupkg`. Therefore, it is necessary to add support for the `.snupkg` format to the `Microsoft.ChakraCore.Symbols.nuspec` file. I will not give an example, because for this it is necessary to make many changes to the `package.ps1` file.

I am ready to implement each of these recommendations in the form of pull request.

Also in the near future I plan to write recommendations for a new structure of NuGet packages. I have already written [something similar for the ClearScript project](https://github.com/microsoft/ClearScript/issues/209), but in this case I also want to give an example of implementation.