Do we want to keep PublishTrimmed a publishing option?

[MichalStrehovsky]

PublishTrimmed is currently a checkbox in the VS publish dialog. We also have docs and blog articles suggesting people publish by adding /p:PublishTrimmed=true parameter to their dotnet command line.

We set several defaults based on PublishTrimmed in the SDK: https://github.com/dotnet/sdk/blob/9ed756ecfe082b738af11a76cabb74742102a0a7/src/Tasks/Microsoft.NET.Build.Tasks/targets/Microsoft.NET.ILLink.targets#L31-L44

The problem with that is that if people specify trimming as part of publish, they'll get different behavior after publishing from the behavior they would get with F5 debug or dotnet run due to feature switches being enabled when publishing, but not when building.

We need to shift the recommendation from "specify trimming as part of publish" to "specify trimming in the csproj".

VS UI should also change.

Cc @vitek-karas @sbomer

[sbomer]

See also dotnet/sdk#14562 (comment). I agree we should recommend setting it in the csproj.

It also might be worth renaming the option to reflect that it no longer just affects publish, especially since Xamarin runs the linker during build, but I'm not sure what would be a good name. How about EnableTrimming? Would we want to do the same for PublishSingleFile/PublishReadyToRun?

[sbomer]

@vitek-karas @agocke is renaming the publish options something we should consider for .NET6?

[agocke]

I think the problem with any name change is that it will only take effect during publish outside Xamarin. It might be pretty confusing if you set EnableTrimming in the project file but don't run publish and nothing happens.

[MichalStrehovsky]

The resolution of this could also be that we just remove the checkbox from the VS publish dialog and update all the docs and blog articles to say "put this in your CSPROJ".

PublishTrimmed is a fine name as long as we only do trimming during publish. Now - I heard there has been some effort to unify what "publish" and "build" means. If it ever comes to that, it's shouldn't be a big issue to come up with a new name of the property and adding a fallback to initialize its value from PublishTrimmed.

[agocke]

I agree -- if we unify publish and build then this problem would go away and we should simplify.

I'm still ambivalent on the idea of removing the checkbox from the publish page. I'm worried that we won't be able to add anything to the project pages in time and the only option will be editing the project file manually. This may be acceptable, but would be far less discoverable.

[agocke]

Thinking about this more: I think it's way too late to change the name of the property now. There's not enough time for users to adapt to the change.

The only change I could see us making this late into .NET 6 is removing the publish option entirely from the publish page.

[MichalStrehovsky]

The idea that trimming doesn't change the behavior of the trimmed apps depends on the "emulation" of feature switches that depend on PublishTrimmed being set to true. If we don't see it set to true in F5 debugging, people will have to troubleshoot their apps at the moment they're ready to ship them.

We had such experience in .NET Native (F5 Debug build was running on CoreCLR that didn't attempt to emulate the F5 Release build based on .NET Native). People didn't like it.

[agocke]

Yup, it's an important concern. I think the big question is: is documentation good enough?

[agocke]

@samsp-msft for thoughts

[samsp-msft]

There are a couple of parts wrapped up in this.

• Publishing with Trimming today, not only trims the app, but also sets some feature flags that could affect app behavior.
• Moving the option to set those flags in F5/debug/dotnet build makes sense. The name PublishTrimmed however doesn't make sense as the name for that property.

My recommendation(s) would be:

• Add a new build flag "DisableUncommonLargeFeatures" (name TBD) that would have the same feature flag behavior as trimming, but would apply to regular builds.
• I am assuming that the Publish Trimmed option in the UI is the way to enable trimming, and its not automatic.
• In the publish dialog, under the publish option in the UI should be a check box for the "RemoveUncommonLargeFeatures" option with text along the lines of "Disable uncommon runtime features from build & Run" which would set that option. That way when users go to enable publshing, they see that there is the extra option that will apply to regular builds.

If these are msbuild properties, I assume we don't need to change msbuild api, its more SDK & targets work?

[samsp-msft]

There are a couple of parts wrapped up in this.

• Publishing with Trimming today, not only trims the app, but also sets some feature flags that could affect app behavior.
• Moving the option to set those flags in F5/debug/dotnet build makes sense. The name publishtrimmed however doesn't make sense for that.

My suggestions:

• Add a new msbuild option "DisableUncommonRuntimeFeatures" that would set the same feature flags as publish trimmed, but applies to regular builds
• Keep the publish trimmed option as we need a way to enable trimming
• Add the DisableUncommonRuntimeFeatures as a checkbox to the publish dialog, with text along the lines of "Disable uncommon runtime features in normal build & Run actions to ensure parity with publishing behavior". That way it can be set by users who care about publish
• This option could be added to regular properties, but that's less important if its included in publish dialog.

[jkotas]

Publishing with Trimming today, not only trims the app, but also sets some feature flags that could affect app behavior

It disables features that are known to be broken with trimming. The primary reason why we are disabling these features with trimming by default is predictabile experience. For example, you will get a nice "built-in COM not support exception" instead of a crash somewhere inside the runtime that only a few interop experts would be able to understand.

I do not think we want a UI checkbox to re-enable features broken with trimming. It is very advanced scenario that should be only used by people who know what their are doing and are capable of dealing with the consequences.

[marek-safar]

I think the problem with any name change is that it will only take effect during publish

That's not entirely true. Trimming during the build will most likely happen for specific workloads for .net6 and I think Uno does that even today with .NET5.

some effort to unify what "publish" and "build" means. If it ever comes to that, it's shouldn't be a big issue to come up with a new name of the property and adding a fallback to initialize its value from PublishTrimmed.

It's true that there is an ongoing effort to make publish to be an alias for dotnet build. There will be some steps made for some workloads in .NET6 but it's gonna take us more than few releases to get there fully.