PublishSelfContained should work with /t:Publish

[eerhardt]

Description

When publishing a trimmed app, I am currently getting an error:

Microsoft.NET.ILLink.targets(196,5): error NETSDK1102: Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. [C:\DotNetTest\SelfContainedTest\SelfContainedTest.csproj]

Even though I'm setting PublishSelfContained=true in my .csproj. I am also setting SelfContained=false because I don't want all of the runtime copied into my build output directory. I have many applications that I'm publishing (test apps in dotnet/aspnetcore) and each application is taking up ~100 MB in the bin directory. This is unnecessary bloat.

Reproduction Steps

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSelfContained>true</PublishSelfContained>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>

    <!-- Set SelfContained=false to prevent the whole runtime from being copied into the build output directory -->
    <SelfContained>false</SelfContained>
  </PropertyGroup>

</Project>

Running dotnet msbuild /t:Publish on that project will fail. It will also fail just for:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSelfContained>true</PublishSelfContained>
  </PropertyGroup>

</Project>

Expected behavior

I expect both apps above to publish successfully.

Actual behavior

Both of them produce the above error.

Regression?

No response

Known Workarounds

Explicitly specify SelfContained=true, but that causes bloat (will eventually be GBs) in my bin directory.

Configuration

No response

Other information

No response

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

Issue Details

---

Description

When publishing a trimmed app, I am currently getting an error:

Microsoft.NET.ILLink.targets(196,5): error NETSDK1102: Optimizing assemblies for size is not supported for the selected publish configuration. Please ensure that you are publishing a self-contained app. [C:\DotNetTest\SelfContainedTest\SelfContainedTest.csproj]

Even though I'm setting PublishSelfContained=true in my .csproj. I am also setting SelfContained=false because I don't want all of the runtime copied into my build output directory. I have many applications that I'm publishing (test apps in dotnet/aspnetcore) and each application is taking up ~100 MB in the bin directory. This is unnecessary bloat.

Reproduction Steps

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSelfContained>true</PublishSelfContained>
    <RuntimeIdentifier>win-x64</RuntimeIdentifier>

    <!-- Set SelfContained=false to prevent the whole runtime from being copied into the build output directory -->
    <SelfContained>false</SelfContained>
  </PropertyGroup>

</Project>

Running dotnet msbuild /t:Publish on that project will fail. It will also fail just for:

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

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net8.0</TargetFramework>
    <PublishTrimmed>true</PublishTrimmed>
    <PublishSelfContained>true</PublishSelfContained>
  </PropertyGroup>

</Project>

Expected behavior

I expect both apps above to publish successfully.

Actual behavior

Both of them produce the above error.

Regression?

No response

Known Workarounds

Explicitly specify SelfContained=true, but that causes bloat (will eventually be GBs) in my bin directory.

Configuration

No response

Other information

No response

Author:	eerhardt
Assignees:	-
Labels:	untriaged, area-Tools-ILLink
Milestone:	-

[sbomer]

Looking at the way PublishSelfContained was implemented:

sdk/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.RuntimeIdentifierInference.targets

Lines 66 to 68 in 4263fdd

	<PropertyGroup Condition="'$(_IsPublishing)' == 'true' and ('$(PublishSelfContained)' == 'true' or '$(PublishSelfContained)' == 'false')">
	<SelfContained>$(PublishSelfContained)</SelfContained>
	</PropertyGroup>

It looks like it just sets SelfContained based on the value of PublishSelfContained when publishing, and all of the downstream publish logic in the SDK continues to use SelfContained. So ILLink won't be the only tool with this problem.

I think that the intention is for this to be resolved via #30038 (so you won't have to explicitly set SelfContained=false to get the desired behavior). There might be a way to work around this by setting SelfContained conditionally only (maybe based on _IsPublishing.

But I think this is currently by design. cc @nagilson

[agocke]

Seems like there's an open question here: is PublishSelfContained set downstream of SelfContained, or vice versa? If the former, there is a bug here.

[nagilson]

PublishSelfContained does not work with MSBuild publish, you need to do dotnet publish or forward the property _IsPublishing to MSBuild publish.

[sbomer]

It looks like there are larger issues here even if you take the "recommended" path and set _IsPublishing. I don't think there's a way to avoid the self-contained build output today: #32277

[eerhardt]

PublishSelfContained does not work with MSBuild publish

That seems like a mistake.

you need to do dotnet publish

When automating the build of a large repo, it doesn't make sense to jump in and out of MSBuild to dotnet publish. I'm already in MSBuild, and I just want to run the Publish target on a set of projects. For example:

https://github.com/dotnet/runtime/blob/c31fda12adf036670ea5c23bce5f066bfd948ebf/eng/testing/linker/trimmingTests.targets#L132-L134

or forward the property _IsPublishing to MSBuild publish.

If we want users to forward/check/set that property, we should give it an official name without an _ at the front

[eerhardt]

I have many applications that I'm publishing (test apps in dotnet/aspnetcore) and each application is taking up ~100 MB in the bin directory. This is unnecessary bloat.

Just an example of this in dotnet/runtime:

https://github.com/dotnet/runtime/tree/main/src/libraries/System.Text.Json/tests/System.Text.Json.Tests/TrimmingTests/Collections

This one folder has 20 trimming tests. When I run them (from the root of dotnet/rutnime):

1. .\build.cmd libs+clr -rc Release
2. .\dotnet.cmd test .\src\libraries\System.Text.Json\tests\System.Text.Json.Tests\TrimmingTests\

and inspect the folder that contains these test projects: artifacts\bin\trimmingTests\projects\System.Text.Json.TrimmingTests:

[nagilson]

That seems like a mistake.

@eerhardt I hear you. We tried very hard to get it to work for MSBuild publish. It also doesn't work inside of VS outside of the context of running a dotnet publish.

There are several reasons we landed here. We could technically create some logic in MSBuild to make it work, but it wouldn't work very well. Adding this to MSBuild would break several key philosophies of MSBuild. One of the problems is that people need to be able to write their own custom publish targets or call the Publish target in their build whenever. We don't know at the very beginning of the build if someone is going to inject a publish target. But we need the _IsPublishing property to be defined by the beginning of the build/publish, as Configuration depends on it as well as properties like PublishSelfContained and PublishRuntimeIdentifier, and for some of these cases any time before the beginning of the build/publish is too late for it to work. @rainersigwald would be able to provide better context.

One of the only ways (if the only) to get around that is to run the build/publish twice, so you can see in the 1st time if publish is ever invoked and commmunicate that to the 2nd run. But that's pretty bad.

If we want users to forward/check/set that property, we should give it an official name without an _ at the front

This is a good suggestion and we could do that. But it sounds like there are problems even if that's used, which is unfortunate. I am trying to think if there is any other solution for this scenario.