With .NET SDK 6.0.300-preview.22154.4, warning NETSDK1179 still shows when running "dotnet publish -r win-x64 --self-contained" in CLI

[WenJunJi01]

Environment: .NET SDK 6.0.300-preview.22154.4 (runtime-6.0.2)

Repro steps:

1. Create an empty solution in CLI
2. Add a new .NET 6.0 console application with reference to a .NET 6.0 class library
3. Run "dotnet publish -r win10-x64“
4. The app can publish successfully and a warning occurs: warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used.
5. Run "dotnet publish -r win10-x64 --self-contained"

Expected Result: Warning NETSDK1179 should not display.

Actual Result: warning NETSDK1179 still shows after adding '--self-contained' or '--no-self-contained'.

Dotnet info: .NET SDK (reflecting any global.json): Version: 6.0.300-preview.22151.9 Commit: c5b0a4598d

Runtime Environment: OS Name: Windows OS Version: 10.0.22000 OS Platform: Windows RID: win10-x64 Base Path: C:\Program Files\dotnet\sdk\6.0.300-preview.22151.9\

Host (useful for support): Version: 6.0.2 Commit: 839cdfb0ec

.NET SDKs installed: 6.0.300-preview.22151.9 [C:\Program Files\dotnet\sdk]

.NET runtimes installed: Microsoft.AspNetCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.AspNetCore.App] Microsoft.NETCore.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App] Microsoft.WindowsDesktop.App 6.0.2 [C:\Program Files\dotnet\shared\Microsoft.WindowsDesktop.App]

To install additional .NET runtimes or SDKs: https://aka.ms/dotnet-download

[waynebrantley]

This issue is in 6.0.3 but works fine in 6.0.202. Upgrading breaks builds. For now, going to force the older 6.0.202 version of dotnet to avoid the issue.

[torepaulsson]

Same issue for us

[mungojam]

Same here with --self-contained false which is meant to work according to the docs: https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli#framework-dependent-executable

[Tealons]

This problem also popped-up in our Azure DevOps pipeline. And in combination with /warnaserror is breaking our build...

[mungojam]

@marcpopMSFT this is affecting customer builds and appears to be a significant regression in the new 6.0.300 SDK. It has currently been pushed to 6.0.4xx, but it surely needs fixing as a priority.

[baronfel]

Brief triage:

• This warning is being fired because _SelfContainedWasSpecified is not set, and so this condition is being evaluated as true, and so the warning is fired
• _SelfContainedWasSpecified is set here, but only for .NETCoreApp framework identifiers where HasRuntimeOutput is set true

I think there may be some corner cases here with libraries (since they don't tend to be targeting .NetCoreApp?) where this condition is never set. We may need a last-chance check for this _SelfContainedWasSpecified property. It seems like the kind of check that could be more general, not necessarily gated behind the condition it currently is. I'm sure there's some context I'm missing though.

[mungojam]

@baronfel what is the official way to specify not self-contained? The docs say it is --self-contained false, but the warning posted above says it should be --no-self-contained.

Maybe that is unrelated to the core issue here

[baronfel]

It is unrelated to the core issue, but has a simple answer: Due to vagueness in the implementation of the options, you can actually use --self-contained false instead of --no-self-contained (and likewise you technically can use --no-self-contained false to mean --self-contained). This is not what I recommend - I would suggest using the flag versions (--self-contained and --no-self-contained) for clarity, and we can work on the documentation/unifying those representations in the docs and the codebase.

[credfeto]

also getting this when upgrading from 6.0.202 to 6.0.300

dotnet publish --configuration Release --output ..\publish-linux-x64 --no-restore --runtime linux-x64 --self-contained /p:SolutionDir=D:\BuildAgent2\work\60950700b4143701\src\ /p:PublishSingleFile=true /p:PublishReadyToRun=false /p:PublishReadyToRunShowWarnings=true /p:PublishTrimmed=false /p:Version=1.1.2.302-ff-3881-update /p:TreatWarningsAsErrors=true /warnaserror /p:IncludeNativeLibrariesForSelfExtract=false -nodeReuse:False

all our exes are built self contained

[nagya]

It seems this was a known regression in 6.0.300 before it was released, what was the rationale of leaving it as-is for the release?

[baronfel]

Folks, a workaround in the interim is:

If you're definitely providing the --self-contained or --no-self-contained flags, you use the NoWarn mechanism to silence NETSDK1179. Adding -p:NoWarn=NETSDK1179 to your command line will do this, as will adding <NoWarn>$(NoWarn);NETSDK1179</NoWarn> to impacted projects (or to many projects via the Directory.Build.props mechanism).

You can see the before and after here:

raw form of the above image

```shell 14:19:37 ❯ dotnet publish -r win10-x64 -bl --self-contained Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET Copyright (C) Microsoft Corporation. All rights reserved. C:\Program Files\dotnet\sdk\6.0.300\MSBuild.dll -bl -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\6.0.300\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\6.0.300\dotnet.dll -maxcpucount -property:SelfContained=True -property:_CommandLineDefinedSelfContained=true -property:RuntimeIdentifier=win10-x64 -property:_CommandLineDefinedRuntimeIdentifier=true -restore -target:Publish -verbosity:m .\app.csproj Determining projects to restore... All projects are up-to-date for restore. C:\Program Files\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(1114,5): warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used. [D:\Code\Sc ratch\6.0-selfcontained\app\app.csproj] C:\Program Files\dotnet\sdk\6.0.300\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.targets(1114,5): warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used. [D:\Code\Sc ratch\6.0-selfcontained\lib\lib.csproj] lib -> D:\Code\Scratch\6.0-selfcontained\lib\bin\Debug\net6.0\lib.dll app -> D:\Code\Scratch\6.0-selfcontained\app\bin\Debug\net6.0\win10-x64\app.dll app -> D:\Code\Scratch\6.0-selfcontained\app\bin\Debug\net6.0\win10-x64\publish\ 14:22:32 ❯ dotnet publish -r win10-x64 -bl --self-contained -p:NoWarn=NETSDK1179 Microsoft (R) Build Engine version 17.2.0+41abc5629 for .NET Copyright (C) Microsoft Corporation. All rights reserved. C:\Program Files\dotnet\sdk\6.0.300\MSBuild.dll -bl -distributedlogger:Microsoft.DotNet.Tools.MSBuild.MSBuildLogger,C:\Program Files\dotnet\sdk\6.0.300\dotnet.dll*Microsoft.DotNet.Tools.MSBuild.MSBuildForwardingLogger,C:\Program Files\dotnet\sdk\6.0.300\dotnet.dll -maxcpucount -property:SelfContained=True -property:_CommandLineDefinedSelfContained=true -property:RuntimeIdentifier=win10-x64 -property:_CommandLineDefinedRuntimeIdentifier=true -p:NoWarn=NETSDK1179 -restore -target:Publish -verbosity:m .\app.csproj Determining projects to restore... All projects are up-to-date for restore. lib -> D:\Code\Scratch\6.0-selfcontained\lib\bin\Debug\net6.0\lib.dll app -> D:\Code\Scratch\6.0-selfcontained\app\bin\Debug\net6.0\win10-x64\app.dll app -> D:\Code\Scratch\6.0-selfcontained\app\bin\Debug\net6.0\win10-x64\publish\ ```

[nagya]

@baronfel, if there's a trivial workaround as you suggest, wouldn't it be overall way less effort to issue a hotfix release that contains the workaround until the issue is properly fixed; as opposed to expecting a multitude of customers to individually and manually apply the workaround, and put them in a precarious position where it's easy to forget about it and permanently disable this warning as an unintended side effect?

[baronfel]

@nagya we're working on a fix quickly in the linked PR and will be taking it to servicing.

[credfeto]

note that the -p:NoWarn=NETSDK1179 doesn't always work - in some of my projects its started failing due to something that was suppressed, which no longer is when this parameter is added

[marcpopMSFT]

We got approval to fix this in 6.0.301 servicing. That is currently planned for release in June.

[waynebrantley]

Great news. However @marcpopMSFT, trying to understand how this issue (which affects many people) was known before release (back on March 8th), but still made it out. Realizing it would affect automated builds everywhere...

[marcpopMSFT]

@waynebrantley we didn't catch during triage that this was different than https://github.com/dotnet/sdk/pull/23999 which we thought we'd already fixed so assumed this issue as much narrower than it was. We'll be reviewing our triage process but folks can also ping us directly to get attention on issues we may be missing.

[waynebrantley]

@marcpopMSFT Hey, things get missed - it happens! As far as the triage process, I was not referring to the ticket you referenced - I was referencing this ticket. Anyway, glad you guys are on it. Thank you very much!!

[WenJunJi01]

Verified on .NET SDK 6.0.301and it is fixed and not repro, so close it.

[Psybax]

It still reproduces for 6.0.403 Error log: /opt/hostedtoolcache/dotnet/sdk/6.0.403/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.targets(1114,5): warning NETSDK1179: One of '--self-contained' or '--no-self-contained' options are required when '--runtime' is used. [/home/vsts/work/1/s/src/KMS/KMS.csproj]

[marcpopMSFT]

Are you using 6.0.403 with 17.4 by any chance?

[gingters]

Please re-open this. I also use .NET SDK 6.0.403 and MSBUILD 17.4.0

This seem to be not fixed and it also happens when calling dotnet clean. Thing is you can't add the --self-contained argument to the clean command. As a workaround, ignoring the warning with -p:NoWarn=NETSDK1179 does work, but this really should be fixed.

[marcpopMSFT]

Per my question above, we have a known issue where we'll still show this warning in the specific combination of 17.4 and 6.0.400. At the moment, we do not have plans to address this though I'm open to continued feedback.

I would like to understand why customers are choosing to use 6.0.400 with 17.4 as .400 includes tooling from 17.3 and is tested with 17.3. While you can overwrite the values through global.json, we don't recommend doing that with Visual Studio/msbuild if you can help it.

[gingters]

Ah, okay. In my current scenario we have still netcoreapp3.1, net6.0 and net7.0 projects together. Migrating them takes time (they grew for a few years ;) ).

So I use the dotnet command with the --framework switch to address them individually. But in this case it's the clean command that produces the warning and for cleaning I can work around that with the NoWarn property on the command. For building and publishing I can provide the --self-contained switch, so that is fine too.

[marcpopMSFT]

Could you try using the 7.0.100 SDK to build all three projects? It should be able to build them and would avoid the issue I mentioned above where 17.4 + 6.0.400 has an issue.