Runtime: Visual Studio issues with building simple console app

[steveharter]

Having issues since recently upgrading to the latest SDK and runtime. When building a simple console app in Visual Studio (Version 16.7.0 Preview 2.0) I get an exception.

However using the basic "dotnet" command line works for building\running. Also, compiling runtime repo source code projects within Visual Studio works fine.

I found that uninstalling the latest SDK (5.0.100-preview.7.20318.2) and installing an older version (5.0.100-preview.6.20314.3) works for me.

Severity    Code    Description    Project    File    Line    Suppression State
Error    MSB4018    The "CreateAppHost" task failed unexpectedly.
System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
File name: 'System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
The Zone of the assembly that failed was:
MyComputer
   at Microsoft.NET.HostModel.AppHost.MachOUtils.RemoveSignature(String filePath)
   at Microsoft.NET.HostModel.AppHost.HostWriter.<>c__DisplayClass2_0.<CreateAppHost>g__RemoveSignatureIfMachO|2()
   at Microsoft.NET.HostModel.RetryUtil.RetryOnIOError(Action func)
   at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom)
   at Microsoft.NET.Build.Tasks.CreateAppHost.ExecuteCore()
   at Microsoft.NET.Build.Tasks.TaskBase.Execute()
   at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
   at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()
  -->

Configuration

.NET SDK (reflecting any global.json):
 Version:   5.0.100-preview.7.20318.2
 Commit:    00203a3818

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.18363
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\5.0.100-preview.7.20318.2\

Host (useful for support):
  Version: 5.0.0-preview.7.20317.2
  Commit:  fa7c99d6b2

.NET SDKs installed:
  5.0.100-preview.7.20318.2 [C:\Program Files\dotnet\sdk]

.NET runtimes installed:
  Microsoft.AspNetCore.App 5.0.0-preview.7.20311.11 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App]
 Microsoft.NETCore.App 5.0.0-preview.7.20317.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  Microsoft.WindowsDesktop.App 5.0.0-preview.7.20311.4 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

[msftbot[bot]]

Tagging subscribers to this area: @vitek-karas, @swaroop-sridhar
Notify danmosemsft if you want to be subscribed.

[hypeartist]

Yep, stumbled upon that issue too. Same build (5.0.100-preview.7.20318.2) and same error. Moreover, after I re-targeted the project to .NET Core 3.1 I still was unable to build (still getting exactly the same error!) util I uninstalled 5.0.100-preview.7.20318.2 - and the project built just fine.

[pr0vieh]

dotnet/sdk#12082

[steveharter]

@Anipik any thoughts on System.Runtime.CompilerServices.Unsafe via:

System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)

[Anipik]

Could be related to we having the preview 6 version in the global.json
https://github.com/dotnet/runtime/blob/master/global.json#L3

@ViktorHofer @safern any thoughts ?

[safern]

Could be related to we having the preview 6 version in the global.json

It seems more like a shared framework/SDK issue in the preview7 version of that SDK where System.Runtime.CompilerServices.Unsafe seems to be missing strong name signature... we should look at the latest SDK with latest dotnet/runtime and see if it is the case and try to scope down the issue.

[ViktorHofer]

From latest:

C:\Users\vihofer\Downloads\dotnet-sdk-5.0.100-preview.7.20319.6-win-x64\shared\Microsoft.NETCore.App5.0.0-preview.7.20318.2System.Runtime.CompilerServices.Unsafe.dll does not represent a strongly named assembly

[safern]

From latest:
C:\Users\vihofer\Downloads\dotnet-sdk-5.0.100-preview.7.20319.6-win-x64\shared\Microsoft.NETCore.App5.0.0-preview.7.20318.2System.Runtime.CompilerServices.Unsafe.dll does not represent a strongly named assembly

Yeah -- I just validated the whole shared framework and same for all assemblies. Looking into why this is the case.

[ViktorHofer]

FWIW, https://github.com/dotnet/installer/pull/7841 is laying around for already three days. So I would check if the signing fix is still not in master/preview7.

[safern]

The signing fix is in, I just doubled checked the authenticode signatures... the signing that was affected by the MSBuild bug is not strong name signing, it is authenticode signing. I just downloaded the assets from the latest official build, the ref pack assets are strong name signed, the runtime assets are not, so this might be related to crossgen or something like that... still narrowing down the issue though.

[ericstj]

Are packages from the same build signed correctly? That would point to crossgen if so. If not, then it would be a signing infra issue).

[safern]

Yeah... that is what I was looking at. Downloaded System.Drawing.Common and verified:

sn -v "C:\Users\Santiago\Downloads\System.Drawing.Common.5.0.0-preview.7.20322.3.nupkg\runtimes\win\lib\netcoreapp3.0\System.Drawing.Common.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'C:\Users\Santiago\Downloads\System.Drawing.Common.5.0.0-preview.7.20322.3.nupkg\runtimes\win\lib\netcoreapp3.0\System.Drawing.Common.dll' is valid

Also, I noted that even older 5.0 shared frameworks have this issue... but maybe preview7 host added a feature to load just valid signed assemblies, so that's why it just manifests with the latest SDK.

Doing a local build now to see which piece of the build is making the signature invalid.

[safern]

Hmm, it seems like it is not crossgen, but it seems like the linker busts the strong name signing:

This is the output from the PreTrim asset

 sn -v "C:\repos\runtime\artifacts\obj\System.Buffers\net5.0-Debug\PreTrim\System.Buffers.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'C:\repos\runtime\artifacts\obj\System.Buffers\net5.0-Debug\PreTrim\System.Buffers.dll' is valid

Output of PostTrim asset:

sn -v "C:\repos\runtime\artifacts\bin\System.Buffers\net5.0-Debug\System.Buffers.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Failed to verify assembly -- Strong name validation failed.

[vitek-karas]

/cc @eerhardt
Do we know how this worked in 3.1? (since we used linker to trim framework assemblies in 3.1 as well)

As for host - I'm not aware of any changes to implement a more strict checks for strong names - in fact .NET Core for the most part doesn't care about strong names (the native host definitely doesn't, the runtime might a tiny little bit). AFAIK none of this changed in 5.

[safern]

As for host - I'm not aware of any changes to implement a more strict checks for strong names - in fact .NET Core for the most part doesn't care about strong names (the native host definitely doesn't, the runtime might a tiny little bit). AFAIK none of this changed in 5.

It seems to only happen when building inside Visual Studio, so I don't know if VS + the new SDK (maybe project system) validate that. @dsplaisted do you know?

Also, I'm curious why signing validation doesn't catch this, is signing validation just running for authenticode @JohnTortugo ?

[ericstj]

It seems to only happen when building inside Visual Studio

It looks like this callstack is from MSBuild. MSBuild is running on desktop in VS. Desktop validates strong-names whereas Core usually doesn't. Perhaps the SDK introduced a component that is doing runtime-loads of assemblies in the build pipeline?

Scratch that, this isn't loading build output. It's running a task and hitting a task dependency. I'd expect an MSBuild task to be cross-compiled for core vs .NETFramework. I'd expect VS to load the .NETFramework version which should carry it's own unmolested copy of System.Runtime.CompilerServices.Unsafe.

[eerhardt]

The interesting thing to me is that it is coming from "CreateAppHost" task, which uses the Microsoft.NET.HostModel package that we produce from src\installer. This package has a super old version of System.Text.Json:

https://github.com/dotnet/runtime/blob/0764d8c11760069056c3f2c4509644c161fce490/src/installer/managed/Microsoft.NET.HostModel/Microsoft.NET.HostModel.csproj#L19

https://github.com/dotnet/runtime/blob/8141ae3fb98ba54205cc6996520de2745cea8d33/eng/Versions.props#L72

Is this fixed if we update that version to a newer System.Text.Json (which will bring in a newer CompilerServices.Unsafe dependency)?

[steveharter]

PTAL @swaroop-sridhar

[safern]

So by looking at System.CompilerServices.Unsafe from where the task is loaded, it seems like it's strong name signing is delayed for some reason:

 sn -v "C:\Program Files\dotnet\sdk\5.0.100-preview.7.20318.2\Sdks\Microsoft.NET.Sdk\tools\net472\System.Runtime.CompilerServices.Unsafe.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

C:\Program Files\dotnet\sdk\5.0.100-preview.7.20318.2\Sdks\Microsoft.NET.Sdk\tools\net472\System.Runtime.CompilerServices.Unsafe.dll is a delay-signed or test-signed assembly

I just downloaded the latest System.CompilerServices.Unsafe that we produced in the last official build and it seems fine:

 sn -v "C:\Users\Santiago\Downloads\System.Runtime.CompilerServices.Unsafe.5.0.0-preview.7.20322.3.nupkg\lib\net45\System.Runtime.CompilerServices.Unsafe.dll"

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'C:\Users\Santiago\Downloads\System.Runtime.CompilerServices.Unsafe.5.0.0-preview.7.20322.3.nupkg\lib\net45\System.Runtime.CompilerServices.Unsafe.dll' is valid

Is this fixed if we update that version to a newer System.Text.Json (which will bring in a newer CompilerServices.Unsafe dependency)?

So maybe that would fix that scenario. However I'm still concerned that the shared fx is not strong name signed.

Do we know how this worked in 3.1? (since we used linker to trim framework assemblies in 3.1 as well)

Tried the same thing in corefx/release/3.1 latest and I saw the same behavior, PreTrim is strong name signed, PostTrim is not.

[swaroop-sridhar]

A similar failure had occurred during a Runtime->SDK update: https://github.com/dotnet/sdk/pull/11150#issuecomment-611552876.

@wli3 do you remember how this got resolved? I think we took a later change from runtime and the problem went away.

[eerhardt]

I grabbed v 5.0.100-preview.7.20319.6 SDK from https://github.com/dotnet/installer#installers-and-binaries

>sn -v F:\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\tools\net472\System.Text.Json.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Assembly 'F:\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\tools\net472\System.Text.Json.dll' is valid

>sn -v F:\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\tools\net472\System.Runtime.CompilerServices.Unsafe.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

F:\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\tools\net472\System.Runtime.CompilerServices.Unsafe.dll is a delay-signed or test-signed assembly

Note this is the issue:

System.Runtime.CompilerServices.Unsafe.dll is a delay-signed or test-signed assembly

Now, why that is delay-signed or test-signed, I'm not sure.

[eerhardt]

OK, I traced this down and the problem is a set of builds from last week that didn't get full strong named signed correctly.

The SDK currently has version 5.0.0-preview.7.20318.2 from the runtime. That build had a signing issue where the delay signed assemblies weren't full signed. The same goes for builds:

• 5.0.0-preview.7.20318.3
• 5.0.0-preview.7.20318.4

And then starting with 5.0.0-preview.7.20318.14 the assemblies started getting fully strong named correctly.

So if the SDK updates to a new version of the runtime this problem will be fixed.

Note that this occurred for all the assemblies that we created in those builds with StrongNameId=Microsoft. I verified that System.Security.AccessControl.dll had the same issue:

>sn -v C:\Users\eerhardt\.nuget\packages\system.security.accesscontrol\5.0.0-preview.7.20318.2\lib\net461\System.Security.AccessControl.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30319.0
Copyright (c) Microsoft Corporation.  All rights reserved.

Failed to verify assembly -- Strong name validation failed.

[safern]

Thanks @eerhardt for finishing chasing down this. This was definitely a fall out from: https://github.com/microsoft/msbuild/issues/5445

And was fixed on: https://github.com/dotnet/runtime/pull/38104.

Will close and we can open an issue on the linker with regards to busting the signature.

[hypeartist]

And then starting with 5.0.0-preview.7.20318.14 the assemblies started getting fully strong named correctly.

@eerhardt Seems like the issue still there:

5.0.100-preview.7.20319.6

1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018: The "CreateAppHost" task failed unexpectedly.
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018: System.IO.FileLoadException: Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. Strong name validation failed. (Exception from HRESULT: 0x8013141A)
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018: File name: 'System.Runtime.CompilerServices.Unsafe, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' ---> System.Security.SecurityException: Strong name validation failed. (Exception from HRESULT: 0x8013141A)
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018: The Zone of the assembly that failed was:
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018: MyComputer
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.NET.HostModel.AppHost.MachOUtils.RemoveSignature(String filePath)
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.NET.HostModel.AppHost.HostWriter.<>c__DisplayClass2_0.<CreateAppHost>g__RemoveSignatureIfMachO|2()
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.NET.HostModel.RetryUtil.RetryOnIOError(Action func)
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.NET.HostModel.AppHost.HostWriter.CreateAppHost(String appHostSourceFilePath, String appHostDestinationFilePath, String appBinaryFilePath, Boolean windowsGraphicalUserInterface, String assemblyToCopyResorcesFrom)
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.NET.Build.Tasks.CreateAppHost.ExecuteCore()
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.NET.Build.Tasks.TaskBase.Execute()
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
1>C:\Program Files\dotnet\sdk\5.0.100-preview.7.20319.6\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(428,5): error MSB4018:    at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__26.MoveNext()

[eerhardt]

@eerhardt Seems like the issue still there:

5.0.100-preview.7.20319.6

There are multiple versions in the product - I was referring to the version of the packages produced by dotnet/runtime. The version you are seeing above 5.0.100-preview.7.20319.6 is the SDK version. You can tell this by the 3rd number, the SDK versions start at x.y.100 (see SDK Versioning).

The change hasn't made its way to the SDK yet. The SDK hasn't taken a new version of the runtime in a while. It looks like it is blocked on this issue: https://github.com/dotnet/installer/pull/7841#issuecomment-648287645