Skip to content

Conversation

hakenr
Copy link
Member

@hakenr hakenr commented Sep 10, 2025

[EDIT by guardrex to add issue]

Fixes #36095

I think saying "never trimmed" is a bit too strong, since you can still enable trimming for your own assemblies and types.


Internal previews

📄 File 🔗 Preview link
aspnetcore/blazor/host-and-deploy/configure-trimmer.md Configure the Trimmer for ASP.NET Core Blazor

@hakenr hakenr requested a review from guardrex as a code owner September 10, 2025 23:00
@Copilot Copilot AI review requested due to automatic review settings September 10, 2025 23:00
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR clarifies the documentation about trimming behavior for custom types in Blazor applications. The changes address the overly strong language of "never trimmed" by adding the important qualifier that custom types can still be trimmed if explicitly opted in by developers.

  • Adds clarification that custom types aren't trimmed "unless explicitly opted in"
  • Updates two instances of the trimming behavior description for consistency

@guardrex
Copy link
Collaborator

guardrex commented Sep 10, 2025

"never trimmed" is a bit too strong, since you can still enable trimming for your own assemblies and types

I don't think it's a significant problem for the sentence because "never trimmed" is followed by "by Blazor," indicating that it's referring to the framework. However, changing it is fine.👍

WRT ...

unless explicitly opted in

Would one create a type that's only used during dev/test and not by the published app?

Also, we don't cover opting-into trimming in dev assemblies for published apps. Even if we add a remark on it, we need to indicate how it's even done in the first place.

This is leaning a bit in the direction of an issue first for discussion, but we could leave this PR open here and come back to it after things are sorted out on an issue.

I opened an issue. Let's discuss further on the issue.

@guardrex
Copy link
Collaborator

guardrex commented Sep 11, 2025

Oh! ... and while we're working on this, there's one little NIT 😈 that we can fix along the way here.

The list items in the blockquote are on one line ...

• 1:T1, 1:T2 • 2:T2, 2:T2

They should be on two lines ...

• 1:T1, 1:T2
• 2:T2, 2:T2

That can be achieved by placing two spaces after the "T2" on the first block quote line.

Let's do that before we merge any changes here.

I think I should also fix the exception in the same way. Two-spaces added to each of the first two lines will fix it.

I'll edit this PR later and fix these items directly. No need for you to take action on them.

@guardrex guardrex self-assigned this Sep 11, 2025
@hakenr
Copy link
Member Author

hakenr commented Sep 11, 2025

Would one create a type that's only used during dev/test and not by the published app?

It's not just a dev/test scenario. For example, a custom type in a reusable class library (not necessarily a widely used NuGet package, but most dev teams create their own helper libraries used across all their projects).

Also, we don't cover opting-into trimming in dev assemblies for published apps. Even if we add a remark on it, we need to indicate how it's even done in the first place.

That would be nice. :-D

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Wording change and trimming types in developer assemblies
2 participants