Visual Studio Publish produces much smaller framework-dependent single-file exe than dotnet publish with identical settings

[ExoticGamerrrYT]

I’m seeing a significant difference in output size between Visual Studio Publish (GUI) and dotnet publish (CLI), even when using what appear to be identical settings.

Project:

• .NET console application
• Target Framework: net10.0
• OS: Windows (win-x64)

Visual Studio Publish settings:

• Configuration: Release
• Deployment mode: Framework-dependent
• Target runtime: win-x64
• Produce single file: enabled
• Enable ReadyToRun: enabled

Result:

• Visual Studio produces a single executable of ~200 KB
• The app runs correctly and requires the .NET runtime to be installed

CLI / PowerShell command:

dotnet publish SpotifyUpdateBlocker.csproj `
  -c Release `
  -r win-x64 `
  --self-contained false `
  /p:PublishSingleFile=true `
  /p:PublishReadyToRun=true `
  /p:TargetFramework=net10.0

Result:

• The generated single-file executable is ~80 MB

Question:
Why does Visual Studio Publish produce a much smaller framework-dependent single-file executable than the CLI, even with the same visible options enabled?

Is Visual Studio applying additional internal MSBuild properties or a different publish pipeline that is not accessible via dotnet publish?

If so:

• Is this behavior documented anywhere?
• Is there a supported way to reproduce the Visual Studio publish output from the CLI (for CI / automation scenarios)?

At the moment it seems impossible to achieve identical output size and behavior outside of Visual Studio, which makes builds non-reproducible between GUI and CLI.

[MadWizardDE]

Unfortunately, I had to make the same observation today.

These are my parameters:

dotnet publish InsomniaServiceHelper.csproj `
  -c Release `
  -o $TargetDirectory `
  -r win-x64 `
  -f net9.0-windows8.0 `
  --self-contained false `
  /p:PublishSingleFile=true `
  /p:PublishReadyToRun=true `

This is the publish configuration:

<?xml version="1.0" encoding="utf-8"?>
<!-- https://go.microsoft.com/fwlink/?LinkID=208121. -->
<Project>
  <PropertyGroup>
    <Configuration>Release</Configuration>
    <Platform>Any CPU</Platform>
    <PublishDir>C:\Users\Wizard\Desktop</PublishDir>
    <PublishProtocol>FileSystem</PublishProtocol>
    <_TargetId>Folder</_TargetId>
    <TargetFramework>net9.0-windows8.0</TargetFramework>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>
    <SelfContained>false</SelfContained>
    <PublishSingleFile>true</PublishSingleFile>
    <PublishReadyToRun>true</PublishReadyToRun>
  </PropertyGroup>
</Project>

It looks like the parameter --self-contained false is being ignored, because I can also use -p:PublishTrimmed=true and -p:EnableCompressionInSingleFile=true, which produces ever smaller files (but not nearly as a framework dependent executable should be sized) and which shouldn't be possible creating a dependent binary in the first place (Visual Studio complains, if I add this to the publish configuration).

By the way this command produces the identical output as publishing the profile in Visual Studio, but actually in the desired directory:

dotnet publish InsomniaServiceHelper.csproj `
  /p:PublishProfile=Alpha `
  -o $TargetDirectory

So Visual Studio does nothing totally different than using the dotnet command. The problem seem to lie in the handling of publish profiles.

I am using the latest public version of the Visual Studio 2026 Insider.

[baronfel]

Two quick pieces of feedback:

• --self-contained false has no impact - the --self-contained option, while accepting a boolean, only ever sets the SelfContained MSbuild property to true. you want --no-self-contained to disable self-contained builds.
  • we have an active issue discussing how we want to handle this - I'm leaning towards deprecating --no-self-contained and enabling the boolean token
• The dotnet CLI doesn't really support publish profiles the same way that VS does. We have a longstanding issue about closing this gap, but to do so could slow down every publish operation that is performed, and it likely would only work for single projects being built - not solutions, etc.

[MadWizardDE]

As it turnes out we seem to be in the first wave of AI sabotaging humanity :D

I ended up with the --self-contained false parameter, because ChatGPT suggested using it and nothing seemed wrong with that. But instead of giving me the correct parameter --no-self-contained, when I asked it for help about this problem, instead it lead me to this issue, so I thought this is a legit bug in the compiler. After commenting I bothered to check out the API of the CLI command myself and directly saw that there is a different parameter for this, feeling rather ashamed of blindly following the AI on this. You gave your reply just the minute I saw my error, @baronfel But thank you for giving final clarity on this!