Bugfix/495 dotnet build #496
Conversation
Fixes microsoft#471 due to missing Microsoft.VisualBasic.dll assembly, and after that an invalid reference to Microsoft.Research/Contracts/MsCorlib/MsCorlib.Contracts.csproj.
Disable sn.exe in VS 2017 code contracts targets, to allow code contracts to build within "dotnet build" or "dotnet test". .NET core does not support sn.exe nor `GetFrameworkSdkPath`
|
If sn.exe doesn’t exist in in .net core sdk, how does it do strong-name signing (on Windows)? |
|
From the examples I've seen (eg https://github.com/aspnet/Logging/blob/dev/Directory.Build.props ), sn.exe is run outside of the |
|
Lines 8 and 9 in that file suggest otherwise. |
|
@yaakov-h : My last comment didn't provide a useful answer. 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. |
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.