Single File publishing is not compatible with Windows 7

[tapika]

I was building ReadyToRun executable from https://github.com/tapika/swupd

build buildexe_choco_win7

and earlier this was working (and still working on build machines where there is older version of Visual studio installed)

I by myself have updated Visual studio to Visual studio 2019, 16.11.7, and same error appeared as I have noticed with newer .net 5.0 and 6.0 frameworks, so error:

 C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(162,5): error NETSDK1180: Speci
fied runtime identifier 'win7-x64'' implies Windows 7 compatibility. Single File publishing is not compatible with Windows 7. [...\src\chocolatey.console\chocolatey.console.csproj]

Command failed: Exit code: 1 ('cmd.exe /c msbuild src\chocolatey_netcoreapp3.1.sln /p:DeployOnBuild=true /p:Configuration=Release /p:Platform="Any CPU
" /t:restore;build;publish /p:PublishDir=bin\publish_win7-x64_netcoreapp3.1\ /p:PublishProtocol=FileSystem /p:RuntimeIdentifier=win7-x64 /p:SelfContained=true /p:PublishSingleFile=true /p:PublishReadyToRun=false /p:IncludeNativeLibrariesForSelfExtract=true /p:IncludeAllContentForSelfExtract=true /p:
PublishTrimmed=true /p:PUBLISH_CHOCO=true')

According to

#60936

this ticket - the intent was:

Because on .NET 6 the runtime is part of the executable (statically linked) and not extracted. On Win7 the runtime needs the
api-ms-..dll shims, and making them part of the executable is really tricky. On .NET 5 and below these files are extracted to disk. We
really wanted to have single-file not extract anything to disk by default in .NET 6, so we prioritized that over Win7 support.

So self-extracting on .net 3.1 should be still supported / working, and new feature is planned for .net 6 or higher - it should not affect .net 3.1 or .net 5.0 framework.

I suspect error handling is incorrect in this case.

C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets:

line 162:    <NETSdkError Condition="'$(PublishSingleFile)' == 'true' and $(RuntimeIdentifier.StartsWith('win7-'))"
                 ResourceName="SingleFileWin7Incompatible"
                 FormatArguments="$(RuntimeIdentifier)" />

This should be .net 6.0 specific error handling, not generic one.

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

I was building ReadyToRun executable from https://github.com/tapika/swupd

build buildexe_choco_win7

and earlier this was working (and still working on build machines where there is older version of Visual studio installed)

I by myself have updated Visual studio to Visual studio 2019, 16.11.7, and same error appeared as I have noticed with newer .net 5.0 and 6.0 frameworks, so error:

 C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets(162,5): error NETSDK1180: Speci
fied runtime identifier 'win7-x64'' implies Windows 7 compatibility. Single File publishing is not compatible with Windows 7. [...\src\chocolatey.console\chocolatey.console.csproj]

Command failed: Exit code: 1 ('cmd.exe /c msbuild src\chocolatey_netcoreapp3.1.sln /p:DeployOnBuild=true /p:Configuration=Release /p:Platform="Any CPU
" /t:restore;build;publish /p:PublishDir=bin\publish_win7-x64_netcoreapp3.1\ /p:PublishProtocol=FileSystem /p:RuntimeIdentifier=win7-x64 /p:SelfContained=true /p:PublishSingleFile=true /p:PublishReadyToRun=false /p:IncludeNativeLibrariesForSelfExtract=true /p:IncludeAllContentForSelfExtract=true /p:
PublishTrimmed=true /p:PUBLISH_CHOCO=true')

According to

#60936

this ticket - the intent was:

Because on .NET 6 the runtime is part of the executable (statically linked) and not extracted. On Win7 the runtime needs the
api-ms-..dll shims, and making them part of the executable is really tricky. On .NET 5 and below these files are extracted to disk. We
really wanted to have single-file not extract anything to disk by default in .NET 6, so we prioritized that over Win7 support.

So self-extracting on .net 3.1 should be still supported / working, and new feature is planned for .net 6 or higher - it should not affect .net 3.1 or .net 5.0 framework.

I suspect error handling is incorrect in this case.

C:\Program Files\dotnet\sdk\6.0.100\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.RuntimeIdentifierInference.targets:

line 162:    <NETSdkError Condition="'$(PublishSingleFile)' == 'true' and $(RuntimeIdentifier.StartsWith('win7-'))"
                 ResourceName="SingleFileWin7Incompatible"
                 FormatArguments="$(RuntimeIdentifier)" />

This should be .net 6.0 specific error handling, not generic one.

Author:	tapika
Assignees:	-
Labels:	area-Single-File, untriaged
Milestone:	-

[PathogenDavid]

I believe you should be able to use global.json to explicitly use the .NET Core 3.1 SDK as a workaround.

Create a file named global.json in the root of your repo with the following contents:

{
  "sdk": {
    "version": "3.1.100",
    "rollForward": "latestFeature"
  }
}

You can check if it's working by running dotnet --version. It should print 3.1.x instead of 6.0.x.

[tapika]

This seems to work - I have tried also to switch to .net 5.0 - it seems to work as well.

Wondering if it's possible just to exclude .net 6.0 or higher ?!

I think ticket can be closed.

[vitek-karas]

I'd like this kept open - we should fix this. The goal of SDK is to be backward compatible - and in this case it isn't. Plus the fix seems pretty simple.

[NN---]

@vitek-karas I see the only missing function to make Windows 7 work is RoInitialize which can be late bound as it is already done in:
mscoree/CMakeLists.txt and in runtime/util.cpp.

There is in threads.cpp a direct call to RoInitialize, however since it is written 7 years ago, I assume it is delay load call.

If singlefilehost.exe used late binding the same way the .NET does, there would be no problem running single file executable in Windows 7.

Could .NET team consider the fix since it should be a minimal with huge impact ?
.NET 6 is LTS and supports M1 unlike .NET 5.

[Genbox]

@vitek-karas i believe this issue has been fixed: #63533

[agocke]

Yes, single-file should now work on Windows 7.

[ALIENQuake]

@agocke Many thanks for this!