PublishTrimmed should imply self-contained

[eerhardt]

Doing the following steps:

• dotnet new console
• dotnet publish -p:PublishTrimmed=true

Results in the following error:

C:\Users\eerhardt\.nuget\packages\microsoft.net.illink.tasks\8.0.100-1.22619.1\build\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\Net8Console\Net8Console.csproj]

However, doing

• dotnet publish -p:PublishAot=true
• -or-
• dotnet publish -p:PublishSingleFile=true

Just works without more command line args.

We should make PublishTrimmed=true imply SelfContained=true, just like PublishAot=true and PublishSingleFile=true does. That way users don't need to pass extra args on the command line, just to make this work.

If in the future we want to support a mode where PublishTrimmed=true, but SelfContained=false, those customers can explicitly --self-contained false. This is consistent with the current PublishSingleFile=true behavior. By default it is self-contained. And you can opt into Framework Dependent Deployment with dotnet publish -p:PublishSingleFile=true --self-contained false.

cc @vitek-karas @sbomer @agocke

@dotnet/linker-contrib a new issue has been filed in the ILLink area, please triage

[agocke]

Surprised that dotnet publish -p:PublishSingleFile=true is self-contained by default. But I don't dislike the behavior. And agree with the proposal about PublishTrimmed.

The only thing I don't like is that these properties affect dotnet build as well. In fact, I don't like self-contained dotnet build at all. I think that should be a publish-only gesture.

[sbomer]

I think this is happening because of the default RID selection. PublishReadyToRun/PublishSingleFile/PublishAot use the current RID, and having a RID currently implies self-contained.

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

Lines 79 to 92 in 201d719

	<UseCurrentRuntimeIdentifier Condition="
	'$(RuntimeIdentifier)' == '' and
	'$(_IsExecutable)' == 'true' and '$(IsTestProject)' != 'true' and
	'$(IsRidAgnostic)' != 'true' and
	(
	'$(SelfContained)' == 'true' or
	('$(_IsPublishing)' == 'true' and
	(
	'$(PublishReadyToRun)' == 'true' or
	'$(PublishSingleFile)' == 'true' or
	'$(PublishAot)' == 'true'
	)
	)
	)">true</UseCurrentRuntimeIdentifier>

But @nagilson is working on a breaking change where RID no longer implies self-contained: #30038.

I expect that after this change, PublishAot will have an error similar to the current one for PublishTrimmed, and the PublishSingleFile default will become framework-dependent. The latter might violate user expectations, but at least will be consistent with the new defaults.

[sbomer]

@marcpopMSFT IIRC you set up the auto-tagging of @dotnet/linker-contrib based on the area labels. The team name changed to @dotnet/illink-contrib. Would you be able to update the bot config?

[marcpopMSFT]

@sbomer see #30152. Feel free to update this in the future if there are changes needed.

[richlander]

Good topic! We're trying to provide coherent behaviors for some things that are similar and others less so. It's sometimes easier when we group the options such that the answer pops out. Let's see if that happens here.

I'm going to use MSBuild syntax, where all properties are intended as true or otherwise have coherent value.

Always framework-dependent:

• [nothing]
• RuntimeIdentifier

Supports both:

• PublishReadyToRun
• PublishSingleFile

Could support both, but only supports self-contained:

• PublishTrimmed

Always self-contained:

• PublishAot
• PublishSelfContained
• SelfContained

There are two ways we could go with this:

• Correctness
• Convenience

There are four groups. The pragmatic choice is make the first two groups fx-dependent by default and the second two are self-contained.

Another observation is that PublishTrimmed is likely not used that often on its own. Instead, we could do the following:

• Require users to specifying self-contained if they use PublishTrimmed
• Default PublishSelfContained to infer PublishTrimmed and require users to disable trimming if they don't want it. We could also infer PublishReadyToRun in the same way.

That approach would have multiple benefits:

• Most of the options would be neutral to the output type (which is good).
• We'd have an option for producing self-contained apps that is good. Most people would agree that the current default for self-contained apps is not polished/optimal.
• Single file would remain a separate concern. The thinking to date is that the various forms of single file should be opt-in since there are more compat considerations with single file variants than with self-contained.

This approach seems to balance CLI consistency with convenience while also most often providing users with a set of artifacts that we would say are "good".

[sbomer]

Default PublishSelfContained to infer PublishTrimmed and require users to disable trimming if they don't want it. We could also infer PublishReadyToRun in the same way.

It's worth noting that PublishTrimmed and PublishReadyToRun can be somewhat at odds, depending on the goals - trimming will remove R2R info and produce the smallest output, while R2R adds back some size in exchange for startup perf.

Single file would remain a separate concern. The thinking to date is that the various forms of single file should be opt-in since there are more compat considerations with single file variants than with self-contained.

It seems like the same reasoning would apply to PublishTrimmed as well - there are compat concerns if we implicitly set PublishTrimmed for PublishSelfContained.

[agocke]

@richlander Based on my comment above, I want to retire SelfContained as it is today. Specifically, I think if you want a self-contained output you should have to use dotnet publish.

[agocke]

A couple more things, actually.

Default PublishSelfContained to infer PublishTrimmed and require users to disable trimming if they don't want it. We could also infer PublishReadyToRun in the same way.

I'm not sure I understand what you're suggesting here. You mean that if PublishSelfContained is true, the default for PublishTrimmed is also true? Or the other way around?

Single file would remain a separate concern. The thinking to date is that the various forms of single file should be opt-in since there are more compat considerations with single file variants than with self-contained.

The compat between self-contained single file and plain self-contained is getting pretty good at this point. It's pretty much just Assembly.Location now.

[richlander]

That's a good point @sbomer. Let's go with that.

I'm thinking about this more. I was trying to get at something with that categorization in my previous post, but I didn't quite know what. I do now.

Let's try again.

App characteristics (don't auto-switch from FDD -> SCD):

• PublishReadyToRun
• PublishSingleFile
• PublishTrimmed
• RuntimeIdentifier

App kind (these auto switch to SCD):

• PublishNativeAot
• PublishSelfContained
• SelfContained

This feels like a more useful categorization, but I still don't find it particularly satisfying. For example, PublishSingleFile feels like it should be an app kind and PublishTrimmed only supports self-contained apps currently.

In the ideal case, users set the minimum values in their project file, like setting PublishSelfContained=true. If they want to try out trimming or single file from the CLI, they will always get the desired result.

I think this conversation comes down to specializing a default project file (like what templates produce) via the CLI. I think a solution like this would help: #26249 (comment). It's basically the same thing as specifying the same values in a project file.

@agocke -- SelfContained ... I'm a little torn on that one. We need to decide once and for all that we're going to stay with publish forever. If we agree to that, then I'm happy to go along with your suggestion. Related: #26247.

@agocke -- I meant that PublishSelfContained could infer PublishTrimmed. I had proposed single file as a default in the past. @jkotas considered that too much of a compatibility risk for opt-out.

Upon further thinking, I think we should go with the categorization I have above and then rely on good project file and CLI gestures to make it easy to adopt the configuration you want. We just added PublishSelfContained and the bad PM for that feature hasn't published a blog post on that yet. I think we don't have enough customer feedback to suggest we need something more dramatic. I'd rather see us make the CLI easier to use to specify defaults for an environment.

[richlander]

@baronfel @dsplaisted

[nagilson]

Thanks everyone for engaging here + internally 😄

@richlander Should we still take this change: #30038 if it does not have PublishAot giving SelfContained by default? Today is the last day for it to get merged (technically Monday at 3 PM...). It sounds like we are OK with this change breaking PublishTrimmed, PublishSingleFile, and PublishReadyToRun such that old usages of these will now have to add SelfContained.

If we have a finalized decision on this, we should close/edit this issue since we've seem to have decided against it, and make one specifically for having PublishAot -> SelfContained, as well as one for PublishSelfContained.