Bugfix/495 dotnet build

[John Crim (johncrim)]

This commit fixes#495 , which I opened. I believe it's reasonable to skip the sn.exe step when building under dotnet, since strong-naming is discouraged for non-.NET Core SDK libraries and apps.

[Yaakov (yaakov-h)]

If sn.exe doesn’t exist in in .net core sdk, how does it do strong-name signing (on Windows)?

[John Crim (johncrim)]

From the examples I've seen (eg https://github.com/aspnet/Logging/blob/dev/Directory.Build.props ), sn.exe is run outside of the msbuild blah.csproj or dotnet build process.

[Yaakov (yaakov-h)]

Lines 8 and 9 in that file suggest otherwise.

[John Crim (johncrim)]

Yaakov (@yaakov-h) : My last comment didn't provide a useful answer. Directory.Build.props defines an msbuild property reference to the .snk file, and properties in that file become part of all the msbuild file in project subdirectories.

However, none of the above answers "how is strong-naming done in dotnet core projects". I haven't yet been able to find an answer to that, but indications are that strong-naming isn't done by the default dotnet msbuild targets. This topic deserves further research before merging my fix.

Framework NuGet package servicing and the GAC don't apply to .NET Core on non-Windows OSes.