New to Telerik UI for Blazor? Download free 30-day trial

Deployment Issues

This page provides information for common issues you may encounter while deploying applications with the Telerik UI for Blazor components.


The Telerik UI for Blazor components consist of:

  • assemblies
  • static assets

Both of these resources are distributed in our NuGet package.

The framework is responsible for copying them from the local NuGet cache to the build/publish target during the build.

The machine that performs the publish build must be able to properly restore the referenced Telerik NuGet packages. This can be our online feed or a local feed.

You can read more about deploying Blazor applications in MSDN - make sure that you are familiar with this information, as the Telerik UI for Blazor suite does not add any specific requirements or steps:

Reported Issues

The Blazor framework is relatively new and there may be unexpected complications or issues during deploy operations. Hopefully, they will get fixed as the framework matures.

At the time of writing, sometimes the following issues have been reported that pertain to the Telerik UI for Blazor suite:

  • 404 not found for telerik-blazor.js - this indicates that the framework did not copy our static assets to the publish location.

    • Some solutions are available in the JS Errors - Missing File article.
    • When using dotnet run or dotnet build to publish an app, the static assets may not work when the ASPNETCORE_ENVIRONMENT is not set to Development. This may be due to a missing server configuration for allowing static assets (MSDN link).

      Usually, the following in Program.cs of the server project solves the problem, or using dotnet publish, or publishing from Visual Studio:


      // Program.cs
      namespace MyBlazorAppName
          public class Program
              //more code may be present here
              //for a server project it may look like this
              public static IHostBuilder CreateHostBuilder(string[] args) =>
                      .ConfigureWebHostDefaults(webBuilder =>
                          webBuilder.UseStaticWebAssets(); // may be needed when ASPNETCORE_ENVIRONMENT is NOT set to Development
              //for a WASM project it may look like this
              public static IWebHost BuildWebHost(string[] args) =>
                      .UseConfiguration(new ConfigurationBuilder()
                      .UseStaticWebAssets() // may be needed when ASPNETCORE_ENVIRONMENT is NOT set to Development
    • On Linux (and often Docker), paths are case-sensitive, so make sure you have the correct casing when registering the styles and scripts (see the Client Assets section of the documentation).

      • Some reports indicate that deploying to a Docker container never copies over the static assets and you may have to either copy the file manually, or use it from our CDN. This may be related to the static asset configurations from the previous points, however.
  • Trial Message - if the machine that performs the build has access to a trial version of our NuGet package, the framework may get confused and copy a trial assembly to the publish location and you may see the trial messages live. Solutions are available in the Upgrade Troubleshooting - I Still See the Trial Message article.

  • Could not load file or assembly 'System.Text.Json, ... - Sometimes this exception is thrown in production (when you deploy the app to another server) when you use things like charts, tooltips or other code that relies on serialization. The usual problem is that the server is missing the corresponding .NET Core version the app was built with. Some reports also indicate that adding explicitly the System.Text.Json package to the Blazor project solves problem.

We have also had reports that hosting a Server-side Blazor app on a cloud service, or even on a server that is relatively remote to the client, causes issues. The network latency may interrupt, break or re-arrange the SignalR packets and this can cause a variety of usability issues - from sluggish responses to wrong UI elements responding, or errors. If your users will have a large latency to the server, you may want to consider the Client-side (WASM) model or at least test what the experience is before rolling out to production.

  • In Azure, for example, WebSockets are disabled by default, and this is detrimental to the performance of the SignalR connection. Enabling WebSockets may help you get the needed speed and responsiveness from the server.

See Also

In this article
Not finding the help you need? Improve this article