1

I searched a lot, read about MsBuild, post-build jobs, csproj-config, but did not succeed with this:

Static files (like css or js) sitting in a Blazor component lib are not copied to the final app's wwwroot folder

What I have:

  • A Blazor webassembly (.Net6, client-side) project as consumer.
  • a Razor-Lib-project as library for reusable controls such as notifications
  • some more, but irrelevant here

The lib has its own wwwroot with css and scripts.

During build the files are finally found in TheConsumerProject\bin\Debug\net6.0\wwwroot. But when debugging with IIS Express (directly from VS) the files should be loaded from TheConsumerProject\wwwroot. That fails... When I copied the files manually it worked.

The goal: Any consumer should not need to configure anything special. Just reference the lib and get all in place.

I found

  • <StaticWebAssetBasePath> to be specified in the lib's csproj but did not manage to get any further with this.
  • hints to <Target> with copy jobs using $(MsBuildVariable). This actually worked, the files were copied to a specified destination, but I did not find a variable pointing to the final app's wwwroot.
  • Some tweaks with <ItemGroup> but nothing worked.

I do NOT want to use any project specific data, like relative paths. This should work with any project structure if possible.

Any ideas?

Shnugo
  • 66,100
  • 9
  • 53
  • 114

1 Answers1

1

The files from the Razor Class Library project should not be copied into the project referencing it (i.e. your Blazor frontend). The runtime does some magical rerouting.

In the page where you want to consume those static assets, you should use a URL such as _content/YourClassLibraryName/path-from-wwwroot. For example, if you have a file like flair.css in your wwwroot folder in the RCL, you would import it in the frontend project as

<link href="_content/YourClassLibraryName/flair.css" rel="stylesheet" />

Similarly, an image file such as solarFlare.png sitting in your wwwroot/img folder would be:

YourClassLibraryName could either be a project name or a NuGet package name, if you're consuming the RCL via NuGet. They should behave the same.

Docs:

Jimmy
  • 27,142
  • 5
  • 87
  • 100