Share via

Is it still the case that a Blazor WebAssembly cannot reference a Blazor Server-Side project?

Falanga, Rod, DOH 980 Reputation points
2025-07-17T20:24:55.4333333+00:00

I'm working on rewriting an old ASP.NET WebForms app. I've created an ASP.NET Core Blazor app using .NET 9, with both a server-side project and a WebAssembly (Client) project. The server-side project has the Home page and allows the user to change the values that can be stored in a cookie. The Blazor Client app will be where the user will enter data to be saved in a database. The server-side project reads the cookie that is stored on the user's machine (assuming they've visited the website before so it could save the cookie on the user's machine). This works fine.

The problem is I wanted to pass the values read from the cookie to the Blazor Client app. I have this in the server-side Program file:

builder.Services.AddScoped<IAppData, AppData>();

The interface IAppData and the class AppData is where I was hoping to put the values retrieved from the cookie. Then I was hoping to do something similar in the Blazor Client app's Program.cs file, however every time I tried to add the server-side Blazor app as a project reference to the Blazor Client app, VS 2022 refused to do it. So, I searched the error which led me to this post on Stack Overflow: https://stackoverflow.com/questions/62841196/blazor-webassembly-unable-to-add-reference-of-library-project-inside-the-client.

That post is from 5 years ago and the answer given was to use .NET Standard Libraries. I'm wondering if the restriction discussed in the SO article from 5 years ago, still applies. If so, how do I use a library project to pass the AppData from the server-side project to the Client project? (The Client project will not modify the contents of the cookie; that is only done in the server-side project.)

Developer technologies | ASP.NET Core | Other
0 comments No comments

Answer accepted by question author

Bruce (SqlWork.com) 84,061 Reputation points
2025-07-17T20:57:42.1766667+00:00

the Blazor client app project can not reference the server app project. the client app runs in the browser as a WASM and can not access any server components.

if you use the new Blazor Web App project structure, and the server project references the Blazor client project, you can use Server pre-render to read the cookie and write to presistant state:

https://learn.microsoft.com/en-us/aspnet/core/blazor/components/prerender?view=aspnetcore-9.0

this works by:

  • the server loads the Blazor code via dll
  • the server run the Blazor app pre-render event. the pre-render can access server DI services
  • the server renders the pre-render output (including any save state)
  • the browser loads the page
  • the browser js load the Blazor WASM app
  • the browser WASM app uses jsinterop to load the state data.

if not using pre-render, then the hosting page, can render the cookie values as a javascript variable, and the Blazor App can use jsinterop to read the values.

if this is a pure Blazor app, you might use local storage rather than a cookie, but pre-render cannot access local storage.

note: neither Blazor Server or Blazor WASM can write a cookie as there is no response to write the cookie to (the request has completed before the Blazor app loads).

Was this answer helpful?

1 person found this answer helpful.
0 comments No comments

1 additional answer

Sort by: Most helpful
  1. Danny Nguyen (WICLOUD CORPORATION) 6,865 Reputation points Microsoft External Staff Moderator
    2025-07-18T08:54:57.5666667+00:00

    Hi Falanga,

    You're correct that Blazor WebAssembly projects still cannot directly reference Blazor Server projects. This fundamental restriction remains in place because:

    1. Blazor Server runs on the server using the full .NET runtime
    2. Blazor WebAssembly runs in the browser using a subset of .NET that's been compiled to WebAssembly

    The architectures are incompatible, so direct project references between them aren't possible.

    Here are some approaches to work around this

    Option 1: Web API Approach (Recommended)

    Server-Side Setup

    • Blazor Server reads the cookie (which it can do natively)
    • Exposes the cookie data via an API endpoint (like /api/appdata)

    Client-Side Access

    • Blazor WebAssembly (client) makes an HTTP request to this endpoint
    • Receives the cookie data as JSON response

    Data Flow

    • User's browser → Blazor Server (reads cookie) → API endpoint → Blazor WebAssembly (consumes data)

    This approach maintains security (cookies stay server-side) while allowing WebAssembly to access the needed data through a clean, standard web interface.

    Server-side (Add a controller):

    [ApiController]
    [Route("api/[controller]")]
    public class AppDataController : ControllerBase
    {
        private readonly IAppData _appData;
        
        public AppDataController(IAppData appData)
        {
            _appData = appData;
        }
        
        [HttpGet]
        public AppData GetAppData()
        {
            // Read cookie and populate AppData
            return _appData.GetCurrentData();
        }
    }
    

    Client-side (Consume the API):

    // In your Blazor WebAssembly component
    @inject HttpClient Http
    
    protected override async Task OnInitializedAsync()
    {
        var appData = await Http.GetFromJsonAsync<AppData>("api/appdata");
        // Use the appData
    }
    

    Option 2: Shared Class Library (.NET 9)

    In case you need to share business logic between client and server, you can create a separate class library project targeting .NET 9 that both projects can reference:

    <!-- SharedModels.csproj -->
    <Project Sdk="Microsoft.NET.Sdk">
      <PropertyGroup>
        <TargetFramework>net9.0</TargetFramework>
      </PropertyGroup>
    </Project>
    

    Put your IAppData interface and AppData class in this shared project.


    In conclusion, I recommend the Web API approach because Blazor WebAssembly cannot directly access cookies, requiring the server to securely pass the data via an API. This keeps architecture clean, avoids .NET Standard workarounds, and ensures security by preventing client-side cookie exposure.

    Hope this helps and please reach out if you have any problem.

    Was this answer helpful?


Your answer

Answers can be marked as 'Accepted' by the question author and 'Recommended' by moderators, which helps users know the answer solved the author's problem.