Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Blazor: Use of --no-build with dotnet publish breaks content with .NET 9 SDK #58321

Closed
1 task done
craigktreasure opened this issue Oct 9, 2024 · 8 comments
Closed
1 task done
Labels
area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug.

Comments

@craigktreasure
Copy link

craigktreasure commented Oct 9, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Describe the bug

TLDR

  • Change in behavior for dotnet publish --no-build when using the .NET 9 SDK, which causes incorrectly named files in the wwwroot folder and breaks content.
  • When the jsmodules.publish.manifest.json resources are not named properly, there is no error indication as to what the problem is.

Explanation

Upon upgrading to use the .NET 9 SDK, my production endpoint began showing as blank. No errors in the console and no 404 errors retrieving resources. Inspecting the page, the body tag has a hidden-body class causing it to be...well...hidden. The loading-theme component also has mode="null", which isn't expected:

<loading-theme storage-name="theme">
  <fluent-design-theme mode="null" primary-color="Default"></fluent-design-theme>
</loading-theme>

If I remove the hidden-body class exposing the page, the theme is not correct. If I attempt to interact with the theme components, I start to see errors in the console:

Error: Microsoft.JSInterop.JSException: Cannot read properties of undefined (reading 'clearLocalStorage')
TypeError: Cannot read properties of undefined (reading 'clearLocalStorage')

None of this occurred building locally whether in or out of a container. I could, however, pull the production container produced by my CI and reproduce the issue.

After more head scratching than I'd care to admit, I discovered that my CI build does dotnet publish --no-build. After comparing the build artifacts, I discovered some files in the wwwroot folder that were different.

.NET 8 SDK with dotnet publish --no-build:
• wwwroot/MyProjectName.modules.json

.NET 9 SDK with dotnet publish --no-build:
• wwwroot/jsmodules.publish.manifest.json

.NET 9 SDK with dotnet publish (--no-build removed):
• wwwroot/MyProjectName.modules.json

The contents of the json files are exactly the same.

It appears that something in .NET 9 SDK with regards to the use of --no-build has changed copying the files with unexpected names.

Workaround

Current workaround is to remove the use of the --no-build parameter for the publish command or rename the files yourself.

Expected Behavior

The MyProjectName.modules.json files should be produced in the publish output as expected.

dotnet build -c Release
# I typically run `dotnet test -c Release --no-build` here before publishing
dotnet publish --no-build # `dotnet publish` does Release configuration by default these days

The commands above should produce the wwwroot/MyProjectName.modules.json file rather than jsmodules.publish.manifest.json.

Using the .NET 8 SDK, everything worked as expected with the use of --no-build.

Steps To Reproduce

See https://github.com/craigktreasure/aspnet-58321-repro for a full repro of the issue.

Build a vanilla .NET 8 Fluent UI Blazor project using the following:

dotnet build -c Release
# I typically run `dotnet test -c Release --no-build` here before publishing
dotnet publish --no-build # `dotnet publish` does Release configuration by default these days

This will produce the wwwroot/jsmodules.publish.manifest.json file in the publish output.

Run the application and view the page to observe a visibly blank page.

Exceptions (if any)

No response

.NET Version

9.0.100-rc.1.24452.12 and 9.0.100-rc.2.24474.11

Anything else?

No response

@dotnet-issue-labeler dotnet-issue-labeler bot added the area-blazor Includes: Blazor, Razor Components label Oct 9, 2024
@javiercn javiercn added the Needs: Repro Indicates that the team needs a repro project to continue the investigation on this issue label Oct 10, 2024
@dotnet-policy-service dotnet-policy-service bot added the Needs: Author Feedback The author of this issue needs to respond in order for us to continue investigating this issue. label Oct 10, 2024
@javiercn javiercn added area-blazor Includes: Blazor, Razor Components and removed area-blazor Includes: Blazor, Razor Components labels Oct 10, 2024
@craigktreasure craigktreasure changed the title Blazor: Use of --no-build with dotnet publish breaks content with .NET 9 Blazor: Use of --no-build with dotnet publish breaks content with .NET 9 SDK Oct 11, 2024
@craigktreasure
Copy link
Author

craigktreasure commented Oct 11, 2024

@javiercn I have added a minimal repro at https://github.com/craigktreasure/aspnet-58321-repro.

@dotnet-policy-service dotnet-policy-service bot added Needs: Attention 👋 This issue needs the attention of a contributor, typically because the OP has provided an update. and removed Needs: Author Feedback The author of this issue needs to respond in order for us to continue investigating this issue. labels Oct 11, 2024
@javiercn
Copy link
Member

@craigktreasure thanks for the additional details.

Found the issue. Was likely moved into a target, and doesn't get set if the --no-build flag is present. To workaround this issue you can simply set it on your csproj the same way we do (see below).

<JSModuleManifestRelativePath Condition="'$(JSModuleManifestRelativePath)' == ''">$(PackageId).modules.json</JSModuleManifestRelativePath>

@javiercn javiercn added bug This issue describes a behavior which is not expected - a bug. and removed Needs: Attention 👋 This issue needs the attention of a contributor, typically because the OP has provided an update. Needs: Repro Indicates that the team needs a repro project to continue the investigation on this issue labels Oct 14, 2024
@javiercn javiercn added this to the .NET 10 Planning milestone Oct 14, 2024
javiercn added a commit to dotnet/sdk that referenced this issue Oct 14, 2024
Fixes #dotnet/aspnetcore#58321

The relative path was defined on a task that only ran during build, and as a result will not be set if you use `publish --no-build` resulting in the file getting copied to the wrong location.
@javiercn
Copy link
Member

This should take care of it dotnet/sdk#44160

@javiercn
Copy link
Member

Fixed by dotnet/sdk#44160

@Bouke
Copy link
Contributor

Bouke commented Nov 19, 2024

@javiercn will this be backported to .NET 9 SDK? This breaks our .NET 8 application.

@javiercn
Copy link
Member

@Bouke are you saying that the fix in #58321 (comment) doesn't work for you?

If so, can you file a separate issue and provide a repro? Note that you can also call publish instead of publish --no-build

@Bouke
Copy link
Contributor

Bouke commented Nov 19, 2024

@javiercn it doesn't work; the published file is named .modules.json. I'm now testing this workaround:

<PropertyGroup Label=".NET 9 SDK shenanigans">
    <JSModuleManifestRelativePath Condition="'$(JSModuleManifestRelativePath)' == ''">$(AssemblyName).modules.json</JSModuleManifestRelativePath>
</PropertyGroup>

@craigktreasure
Copy link
Author

Agree. This is not a new issue. The original issue is not fixed. I've updated my repro to the .NET 9.0.100 SDK and the issue still exists.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
area-blazor Includes: Blazor, Razor Components bug This issue describes a behavior which is not expected - a bug.
Projects
None yet
Development

No branches or pull requests

3 participants