blazor webapp production optimizations #10759

2 Answer(s)

• 

  0

  AI-Bot created 3 months ago

  Support Team ABP Agent

  Please contact us at https://abp.io/contact.

  ---

  This response was generated by AI. If it didn’t solve your problem, feel free to post a new answer — our support team will jump in to help you soon.

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel
• 

  0

  maliming created 3 months ago

  Support Team Fullstack Developer

  Hi,

  The short answer on the cold-start side: full IL trimming and WASM AOT won't work cleanly with ABP, so they're not the lever to pull here. ABP's runtime is reflection- and proxy-heavy by design — convention-based DI scans module assemblies/types/attributes at startup, UoW/auditing/validation interception goes through Castle DynamicProxy, and DTO serialization over the client proxies is reflection-based System.Text.Json (a plain DefaultJsonTypeInfoResolver, no source-generated JsonSerializerContext). The ~490 warnings you measured in Castle.DynamicProxy / Autofac / Volo.Abp land on exactly that surface. We don't ship trimmer-safety metadata ([DynamicDependency], ILLink.Descriptors.xml, [DynamicallyAccessedMembers], [RequiresUnreferencedCode]) for those paths, so those warnings aren't noise you can wave through — they're real, unannotated trim risks, including the silent DTO-drop case you're worried about.

  Going through your list:

  | Area | Where it lands | |------|------| | A. PublishTrimmed (WASM) | Don't. No trimmer-safety metadata is shipped; convention-based DI scanning, Castle interception and reflection-based STJ all rely on metadata the trimmer can remove. | | A3. DTO round-trip under trimming | Not a safe boundary. Serialization is reflection-based and ABP doesn't root the DTO contracts, so round-trips aren't guaranteed. There's no ABP-provided descriptor or source-gen context to root them. | | A4. Trim runtime only, keep Volo.Abp.* / Castle.* whole | You can root them with TrimmerRootAssembly, but that mainly turns trimming back off for the risky ABP surface — it preserves metadata/code rather than making the reflection paths trim-safe. The remaining saving comes from the framework and other non-rooted assemblies, and it's not a config we test, so you'd own the validation. | | B. RunAOTCompilation (WASM) | Same trim-analysis problem, plus Castle-based interception and any dynamic HTTP client-proxy path use runtime proxy generation, so AOT isn't a clean switch for this stack. The static Pro client proxies avoid the dynamic HTTP-proxy generation, but they still use the same reflection-based JSON and ABP startup surface. | | C. PublishSingleFile (host) | Not a useful shape here. The executable won't actually carry the Blazor/static payload as one file — static web assets, wwwroot content, generated _framework assets and the compressed files stay as sidecar files next to it. Use the normal folder/container publish output for the host. | | C7. WasmEnableWebcil | Keep the default (true) — that's the right packaging. | | D. Bounded ICU / custom culture shard | Not something ABP provides or tests. The template keeps BlazorWebAssemblyLoadAllGlobalizationData on because the WASM client gets its culture from the server and switches among the configured languages at runtime; keep it on unless you fully own and test a custom culture set. | | E. BlazorWebAssemblyLazyLoad for Pro modules | Won't work for the Pro modules. Blazor lazy loading can defer ordinary route assemblies, but the modules in the [DependsOn] graph are startup dependencies — their types have to be available before ABP startup runs, since each module's ConfigureServices executes at app init. So admin modules can't be split out per route while they're ABP modules in the startup graph. | | F. Compressed static assets behind a proxy | Works. ABP 10 uses MapAbpStaticAssets, which serves the ABP virtual-file/dynamic bundle files and then calls ASP.NET Core MapStaticAssets. Serving notes below. | | G. Server-side PublishReadyToRun | Fine for the host (R2R doesn't strip metadata). Publish it for your deploy RID (-r linux-x64). Just don't combine the host with trimming or NativeAOT — same reflection reasons as the WASM side. |

  A concrete set you can pin. These split across two projects — the WASM knobs go in the client project, not the host:

  <!-- host project (Microsoft.NET.Sdk.Web) -->
  <PropertyGroup>
    <PublishReadyToRun>true</PublishReadyToRun>
  </PropertyGroup>
  

  <!-- WASM client project (Microsoft.NET.Sdk.BlazorWebAssembly) -->
  <PropertyGroup>
    <BlazorWebAssemblyLoadAllGlobalizationData>true</BlazorWebAssemblyLoadAllGlobalizationData>
    <WasmEnableWebcil>true</WasmEnableWebcil>
    <!-- Do NOT enable PublishTrimmed, RunAOTCompilation or InvariantGlobalization for the ABP client. -->
  </PropertyGroup>
  

  SatelliteResourceLanguages is worth setting only if you're intentionally limiting UI satellite resources to a fixed set of languages — with Language Management and runtime language switching in the picture, don't blanket-pin it to en.

  Where the cold-start wins actually are for your stack (no reflection risk):

  • Keep WebCIL + Brotli (already produced by dotnet publish -c Release). Serve the precompressed _framework/*.br directly and let the client negotiate; don't recompress at runtime.
  • Behind a reverse proxy, either Kestrel or the proxy can serve the precompressed framework files — pick one, just don't double-compress. Serve the fingerprinted WASM assets with Cache-Control: public, max-age=31536000, immutable; the filenames change on rebuild, so long immutable caching is safe.
  • ABP's runtime-generated bundles (the LeptonX global bundles) are written into the dynamic file provider at startup and served through ABP's virtual/static-file middleware, not through the publish-time precompressed-asset pipeline — so treat those as normal static responses and let the proxy/Kestrel compress them if you want them compressed.
  • Make sure HTTP/2 (or HTTP/3) is on at the proxy so the ~180 _framework requests multiplex on one connection instead of paying per-request overhead.

  So the lever for your setup is transport (WebCIL + Brotli + immutable caching + HTTP/2), not trimming/AOT.

  Thanks

  Markdown supported.

  Copy, paste, or drag & drop images and files (max 100 MB per file, 100 MB total per post)

  Save Cancel