dotnet publish with -p:PublishProfile=DefaultContainer results in infinite loop

[JeroMiya]

Describe the bug

After updating to .net 9.0.104 SDK, attempting to publish a docker image from a .net 8 project with the -p:PublishProfile=DefaultContainer option results in an infinite loop, continuously rebuilding assemblies.

To Reproduce

Create a new Asp.Net Core API project in Visual Studio, enable containerization support. I also enabled Aspire support.

Here is the csproj for reference:

<Project Sdk="Microsoft.NET.Sdk.Web">

  <PropertyGroup>
    <TargetFramework>net8.0</TargetFramework>
    <Nullable>enable</Nullable>
    <ImplicitUsings>enable</ImplicitUsings>
    <RuntimeIdentifiers>linux-x64</RuntimeIdentifiers>
    <EnableSdkContainerDebugging>True</EnableSdkContainerDebugging>
    <ContainerBaseImage>mcr.microsoft.com/dotnet/aspnet:8.0</ContainerBaseImage>
    <UserSecretsId>59426953-6aea-4add-887b-24d737da612c</UserSecretsId>
  </PropertyGroup>

  <ItemGroup>
    <PackageReference Include="Swashbuckle.AspNetCore" Version="6.6.2" />
  </ItemGroup>

  <ItemGroup>
    <ContainerPort Include="8081" />
  </ItemGroup>

  <ItemGroup>
    <ProjectReference Include="..\AspNetDockerTemplate.ServiceDefaults\AspNetDockerTemplate.ServiceDefaults.csproj" />
  </ItemGroup>

</Project>

From the command line within the API project directory, attempt to publish the project using the following command:
dotnet publish --configuration Debug --os linux --arch x64 -p:PublishProfile=DefaultContainer

Result: build goes into infinite loop, rebuilding the API and (in my case, since I enabled Aspire, the servicedefaults project) over and over again endlessly.

Exceptions (if any)

Further technical details

• Include the output of dotnet --info
• The IDE (VS / VS Code/ VS4Mac) you're running on, and its version

Visual Studio: 17.12.4

dotnet --info:

.NET SDK:
 Version:           9.0.102
 Commit:            cb83cd4923
 Workload version:  9.0.100-manifests.4a54b1a6
 MSBuild version:   17.12.18+ed8c6aec5

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.26100
 OS Platform: Windows
 RID:         win-x64
 Base Path:   C:\Program Files\dotnet\sdk\9.0.102\

.NET workloads installed:
 [wasm-tools-net8]
   Installation Source: VS 17.12.35707.178
   Manifest Version:    9.0.1/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.net8\9.0.1\WorkloadManifest.json
   Install Type:              Msi

 [aspire]
   Installation Source: VS 17.12.35707.178
   Manifest Version:    8.2.2/8.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\8.0.100\microsoft.net.sdk.aspire\8.2.2\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools-net6]
   Installation Source: VS 17.12.35707.178
   Manifest Version:    9.0.1/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.net6\9.0.1\WorkloadManifest.json
   Install Type:              Msi

 [wasm-tools]
   Installation Source: VS 17.12.35707.178
   Manifest Version:    9.0.1/9.0.100
   Manifest Path:       C:\Program Files\dotnet\sdk-manifests\9.0.100\microsoft.net.workload.mono.toolchain.current\9.0.1\WorkloadManifest.json
   Install Type:              Msi

Configured to use loose manifests when installing new manifests.

Host:
  Version:      9.0.1
  Architecture: x64
  Commit:       c8acea2262

.NET SDKs installed:
  9.0.102 [C:\Program Files\dotnet\sdk]

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

Other architectures found:
  x86   [C:\Program Files (x86)\dotnet]
    registered at [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x86\InstallLocation]

Environment variables:
  Not set

global.json file:
  Not found

Learn more:
  https://aka.ms/dotnet/info

Download .NET:
  https://aka.ms/dotnet/download

[vRune4]

After updating to .net 9.0.104 SDK, attempting to publish a docker image from a .net 8 project with the `-

9.0.102 SDK.

My github workflow was also broken by 9.0.102. I had to downgrade to 9.0.101 if I wanted to publish anything.

[baronfel]

@JeroMiya is your publish broken if you move off of the legacy -p PublishProfile=DefaultContainer mechanism and onto the more-broadly usable -t:PublishContainer method? We stopped recommending DefaultContainer a few versions back because it doesn't work well for all kinds of containerization.

[JeroMiya]

@JeroMiya is your publish broken if you move off of the legacy -p PublishProfile=DefaultContainer mechanism and onto the more-broadly usable -t:PublishContainer method? We stopped recommending DefaultContainer a few versions back because it doesn't work well for all kinds of containerization.

Ah, yes, using -t:PublishContainer works. I wasn't aware the recommendation changed. Thanks! Should I close, or should -p PublishProfile=DefaultContainer still work? This is technically a regression from the .net 8 sdk. I would have preferred an error to an infinite build loop.

[baronfel]

It is a regression, and we probably need it to work for VS scenarios to remain good to go, so let's keep this open. I'm just glad you're unblocked :)

[mortenlaursen]

After upgrading to .NET 8.0.405, I encountered the same issue and was able to resolve it with the following changes:

I found that replacing RuntimeIdentifiers with RuntimeIdentifier resolved the problem. If needed, ContainerRuntimeIdentifier can also be used.

Testing the -t:PublishContainer option resolves the issue as well, and we will use that approach going forward. :)

[JeroMiya]

I did notice a difference between -t:PublishContainer and the previous behavior of -p:PublishProfile=DefaultContainer when it comes to image tags. With -t:PublishContainer, the dotnet publish command will ALWAYS add a -linux-x64 to whatever container image tag you specify with either ContainerImageTag or ContainerImageTags. I'm not aware of any way to set the tag to something specific without the OS/arch suffix (and this behavior is not documented in the documentation - is it a bug or just undocumented behavior?).

So, I'm forced to manually run docker tag to re-tag the image after it is built with the latest tag before publishing the image to a registry. I also used to be able to add windows-x64 to RuntimeIdentifiers to allow for publishing to both windows and docker (we're temporarily using docker for local dev and automated testing, and publishing to windows/IIS), but the docker publish command no longer allows this. I have to remove windows-x64 from the RuntimeIdentifiers and override it back when I publish the windows output.

[baronfel]

@JeroMiya The behavior you're seeing is a result of the bug that shipped in 9.0.102/8.0.405 and will be resolved with February's release. In the meantime you should be able to pin to 9.0.101/8.0.404 and get the behavior you expect.

[jeffreywstevens]

@baronfel
The Dotnet publish container simplified a lot of the problems we had when authenticating with many different internal Nuget feeds.

The -t:PublishContainer solved the infinite loop.

Is -t:PublishContainer no longer recommended too? Should we go back to using docker files to build containers instead?

[baronfel]

@jeffreywstevens -t:PublishContainer remains the recommended way. What folks are hitting is #46053, which we've fixed in #46067, which will release next month according to our standard servicing schedule. If you are blocked today, I highly suggest using a global.json file to pin the version of the SDK that is used by the dotnet CLI and other tooling.

[jeffreywstevens]

@baronfel, I was mainly concerned with building a container with "Dotnet-Publish" getting discouraged because it is getting deprecated in the future.
If not, I am good. If so, I will go back to the Dockerfile now.