Blazor wasm client fails to start when PublishTrimmed=true and built using 7.0.201 and above

[markphillips100]

Describe the bug

I have a Blazor WASM hosted 7.0 project with the following settings:

<PublishTrimmed>true</PublishTrimmed> 
<EnableTrimAnalyzer>true</EnableTrimAnalyzer>
<TrimMode>partial</TrimMode>

There is code that likely cannot be trimmed I'm sure, reflection, dynamic components, etc, however, when the client (and host) app is built using 7.0.103 sdk the app exhibits no runtime issue with these trim settings.

I build and deploy using a dockerfile with a base sdk image. SDKs 7.0.104 and 7.0.200 did not get docker image releases so cannot try those versions. Using SDK 7.0.201 and the recent 7.0.202 causes the exception below in the browser when the app starts up.

If I set PublishTrimmed=false then no trimming occurs of course but the app also works normally, so this appears to be some trim behaviour introduced in 7.0.201 (and perhaps 7.0.200 but I cannot test for that). Are there any things trim-wise that could be affecting the app at startup in these new versions, or is their even some diagnostics I can setup to try and get to the bottom of what might be the issue?

To Reproduce

Unfortunately I cannot create a repro.

Exceptions (if any)

Further technical details

[markphillips100]

I've tested using a new template wasm hosted project and used the Visual Studio generated Dockerfile for the server project to compare against my Dockerfiles.

Seems I was specifying /p:PublishSelfContained=$SELF_CONTAINED on the RUN dotnet publish.... where SELF_CONTAINED is an argument I can use to control trimming and self contained or not. Whilst this was fine in 7.0.103 SDK, in the newer versions having this msbuild property (with a false value) causes the exception when the client csproj has PublishTrimmed set to true (which is the default anyway).

If I don't specify the property all is fine. So it seems setting the property to a false value is not quite the same as not providing the value in the first place. All my csproj only react to a true value so must be a change in behaviour in the SDK is my guess.

Note: My SELF_CONTAINED argument was always set false.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 8 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[javiercn]

@markphillips100 thanks for contacting us.

Is it correct that this is a hosted blazor project? Can you add <GlobalPropertiesToRemove>SelfContained</GlobalPropertiesToRemove> to the project reference of the webassembly application?

[markphillips100]

@javiercn it is indeed a blazor webassembly hosted project.

My solution was to just not supply the PublishSelfContained at all when building in my dockerfile for the use case where I don't want it self contained. I'm happy with that as it does work but just wanted to know if the behaviour of this particular property had been changed as my previous setup with the 103 patch worked fine setting it to false explicitly.

[javiercn]

@markphillips100 the behavior in this area has been changing, I am not sure if it did in the 7.0.x SDK, but this has always been "problematic" due to the way the arguments passed for the CLI worked. In general, Blazor requires SelfContained to always be true, and some combinations of the CLI can cause it to be false.

Due to how MSBuild works, its a bit tricky to get it working (I was actually trying to get this to work myself and that's the best I've got so far)

The problem is that what you specify on the CLI applies to all projects and overrides the individual project preferences

[markphillips100]

That's okay @javiercn. There's probably more changes over the horizon too at a guess :-). Self contained is always the goal for me but had problems with v7 due to some partial trim mode performance issues hence needing to turn it off. The linker team worked wonders and brought forward fixes from v8 into 7.0.300 so should be good to go self-contained (partial trim mode) when that is released.

Happy to close the issue.

[javiercn]

@markphillips100 if setting <GlobalPropertiesToRemove>SelfContained</GlobalPropertiesToRemove> in the project reference does not work with what you are passing via command-line, please let us know.

You should be able to do selfcontained builds for the host or framework dependent builds of the host without that affecting the webassembly app (provided that you specify the setting above)

[ghost]

Hi @markphillips100. We have added the "Needs: Author Feedback" label to this issue, which indicates that we have an open question for you before we can take further action. This issue will be closed automatically in 7 days if we do not hear back from you by then - please feel free to re-open it if you come back to this issue after that time.

[markphillips100]

@javiercn I added the MSBuild property to the project reference in the host csproj like so, I assume this is correct?

    <ProjectReference Include="..\MySample.Client\MySample.Client.csproj" >
      <GlobalPropertiesToRemove>SelfContained</GlobalPropertiesToRemove>
    </ProjectReference>

Switching my dockerfile back to the original RUN dotnet publish ... /p:PublishSelfContained=false ... and I get the same client-side exception as before.

Did I add the GlobalPropertiesToRemove correctly?

[javiercn]

@markphillips100 you did.

Can you capture a binlog with the /bl flag? Be careful to inspect it in case you have secrets in environment variables or similar, as they might appear on the build log.

[markphillips100]

@javiercn no secrets in this one as this is just an isolated sample template blazor hosted app. App is part of existing solution which does use central package management so might see some custom named dlls however these aren't actually referenced by the app at all. App is essentially a raw wasm hosted template with central package enabled. FYI central package management enabled using <ManagePackageVersionsCentrally>true</ManagePackageVersionsCentrally>.

The local dev inner loop builds a docker image containing the app and publishes to a local k8. So the dotnet build and publish steps are all in the dockerfile.

I deployed the sample app without specifying PublishSelfContained property set to just confirm this sample works and all good. Then switch back to my original RUN dotnet publish with the PublishedSelfContained=false and also the GlobalPropertiesToRemove specified in host project reference. Confirmed still fails and the binlog is in the attached zip.

msbuild.binlog.zip

[javiercn]

@markphillips100 can you try this?

    <ProjectReference Include="..\MySample.Client\MySample.Client.csproj">
      <GlobalPropertiesToRemove>SelfContained;RuntimeIdentifier;PublishSelfContained</GlobalPropertiesToRemove>
    </ProjectReference>

Might also need to add the following inside a propertygroup

<StaticWebAssetsAdditionalBuildPropertiesToRemove>$(StaticWebAssetsAdditionalBuildPropertiesToRemove);RuntimeIdentifier;SelfContained;PublishSelfContained</StaticWebAssetsAdditionalBuildPropertiesToRemove>

[markphillips100]

So tried both changes together but it doesn't get past the RUN dotnet build step due to an error (shown below).

Thought I'd try one change at a time.

GlobalPropertiesToRemove	StaticWebAssetsAdditionalBuildPropertiesToRemove	Builds	Runtime error
SelfContained	Not specified	Yes	Yes
SelfContained;RuntimeIdentifier	Not specified	Yes	Yes
SelfContained;RuntimeIdentifier;PublishSelfContained	Not specified	No	Not possible

The build error from the last set of properties used is: /usr/share/dotnet/sdk/7.0.202/Sdks/Microsoft.NET.Sdk.BlazorWebAssembly/targets/Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(238,5): error : The process cannot access the file '/src/src/EziEventShop.SampleWeb.Client/obj/Release/net7.0/build-gz/tx8NU7vJ.gz' because it is being used by another process. [/src/src/EziEventShop.SampleWeb.Client/EziEventShop.SampleWeb.Client.csproj]

I then tried adding the StaticWebAssetsAdditionalBuildPropertiesToRemove iteratively adding the same respective combination of the delimited property values but experienced the same outcomes:

GlobalPropertiesToRemove	StaticWebAssetsAdditionalBuildPropertiesToRemove	Builds	Runtime error
SelfContained	SelfContained	Yes	Yes
SelfContained;RuntimeIdentifier	SelfContained;RuntimeIdentifier	Yes	Yes
SelfContained;RuntimeIdentifier;PublishSelfContained	SelfContained;RuntimeIdentifier;PublishSelfContained	No	Not possible

I tried just specifying PublishSelfContained alone but got this error during RUN dotnet build step:

 /usr/share/dotnet/sdk/7.0.202/Sdks/Microsoft.NET.Sdk.BlazorWebAssembly/targets/Microsoft.NET.Sdk.BlazorWebAssembly.6_0.targets(319,5): error MSB4018: System.IO.IOException: The process cannot access the file '/src/src/EziEventShop.SampleWeb.Client/obj/Release/net7.0/blazor.boot.json' because it is being used by another process. [/src/src/EziEventShop.SampleWeb.Client/EziEventShop.SampleWeb.Client.csproj]

[javiercn]

@markphillips100 is there a chance that you can create a minimal repro project so that we can take a look? As a public github repository we can clone and access.

[markphillips100]

@javiercn I shall give it a go tomorrow as getting late here :-). Might make things a bit easier with a sample repro for sure.

I'll see if I can repro using regular file publish (I'm on windows) and also do a dockerfile for a WSL2 Docker 4 Desktop deploy if the file publish has no issue.

Will check back with you tomorrow-ish.

[javiercn]

@markphillips100 thanks.

No rush!

[markphillips100]

@javiercn as promised I created a really basic repro at https://github.com/markphillips100/blazorwasm-selfcontained-sample. Hope it helps, and let me know if you need anything else.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[ghost]

Thanks for contacting us.

We're moving this issue to the .NET 9 Planning milestone for future evaluation / consideration. We would like to keep this around to collect more feedback, which can help us with prioritizing this work. We will re-evaluate this issue, during our next planning meeting(s). If we later determine, that the issue has no community involvement, or it's very rare and low-impact issue, we will close it - so that the team can focus on more important and high impact issues. To learn more about what to expect next and how this issue will be handled you can read more about our triage process here.

[MackinnonBuck]

@markphillips100, we think we might have fixed this in .NET 8. Could you please try using .NET 8 and see if it resolves the problem?

[markphillips100]

Sorry I should have commented earlier. It's been working great with 8.0.100.

Thanks for everyone's efforts.