dotnet / aspnetcore

ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
https://asp.net
MIT License
35.37k stars 9.99k forks source link

Parameters from Static Server component to WebAssembly component fail when parameter type defined in separate project #53013

Closed sentai77 closed 10 months ago

sentai77 commented 10 months ago

Is there an existing issue for this?

Describe the bug

When using a Blazor application structured into three projects (WebApp, WebApp.Client, and SharedLibrary), I encounter an unexpected behavior. The application consists of a static server-side rendered page (/person-page) in WebApp, which embeds an interactive WebAssembly component (PersonDetails) from WebApp.Client. This component is designed to receive a "Person" model (name and age) as a parameter, which is defined in a SharedLibrary project.

Upon navigating to /person-page, the interactive component fails to render and the following JavaScript exception is thrown: Error: One or more errors occurred. (The parameter 'Person' with type 'SharedLibrary.Person' in assembly 'SharedLibrary' could not be found.)

Note that:

  1. The render mode of the interactive component should be set to @rendermode @(new InteractiveWebAssemblyRenderMode(prerender: false)). If the component is prerendered or set to Interactive Auto, then it will initially render successfully, then fail when switching to Web Assembly.
  2. In launch settings, launchBrowser should be set to false. The auto-launched browser does not raise the error for reasons I do not understand.

Expected Behavior

The person object is serialized, passed to the web assembly component, deserialized correctly, then rendered.

Steps To Reproduce

https://github.com/sentai77/BlazorParameterBug/tree/main

Exceptions (if any)

blazor.web.js:1 Error: One or more errors occurred. (The parameter 'Person' with type 'SharedLibrary.Person' in assembly 'SharedLibrary' could not be found.) at Jn (marshal-to-js.ts:349:18) at Ul (marshal-to-js.ts:306:28) at dotnet.native.wasm:0x1faca at dotnet.native.wasm:0x1bf8b at dotnet.native.wasm:0xf172 at dotnet.native.wasm:0x1e7e4 at dotnet.native.wasm:0x1efda at dotnet.native.wasm:0xcfec at dotnet.native.wasm:0x440ad at e. (cwraps.ts:338:24) callEntryPoint @ blazor.web.js:1 await in callEntryPoint (async) ei @ blazor.web.js:1 await in ei (async) Zr @ blazor.web.js:1 startWebAssemblyIfNotStarted @ blazor.web.js:1 resolveRendererIdForDescriptor @ blazor.web.js:1 determinePendingOperation @ blazor.web.js:1 refreshRootComponents @ blazor.web.js:1 (anonymous) @ blazor.web.js:1 setTimeout (async) rootComponentsMayRequireRefresh @ blazor.web.js:1 onDocumentUpdated @ blazor.web.js:1 Ji @ blazor.web.js:1

.NET Version

8.0.100

Anything else?

No response

javiercn commented 10 months ago

@sentai77 thanks for contacting us.

This is a known issue that was fixed recently. A fix will be available in 8.0.1 in a future release. As a workaround you can use GC.KeepAlive(typeof(Person)) in the webassembly project to make sure that the assembly is loaded into memory by the time we try to deserialize it.

Dupe of https://github.com/dotnet/aspnetcore/issues/52129