Support for .NET 10, Blazor WebAssembly, Multi-Project Solutions, and WASM Tools in Dokploy

What problem will this feature address?

Currently, Dokploy does not fully support modern .NET 10 and Blazor WebAssembly applications. Blazor WASM requires correct handling of static files, fingerprinted assets, Brotli/Gzip compression, and pre-build WASM tools.
Additionally, many .NET developers work with multi-project solutions inside a single GitHub repository (e.g., API + WASM + Shared libraries). Dokploy’s GitHub integration makes it difficult to specify which project inside the solution should be built and deployed, leading to limitations when working with Clean Architecture or multi-project monorepos.
Finally, Blazor WASM requires the wasm-tools workload before building, and there is currently no option in Dokploy to install it before running the build, which causes the build to fail.

Describe the solution you'd like

I would like to request first-class support for modern .NET and Blazor:

1. .NET 10 Support
   • Ability to build and deploy .NET 10 applications directly in Dokploy.

2. Blazor WebAssembly Static Hosting Support
   • Proper hosting of published Blazor WASM output from dotnet publish.
   • Serve fingerprinted/hashed files correctly (app.bundle..js, _framework assets, etc.).
   • Automatic Brotli (.br) and Gzip (.gz) file serving.
   • Correct MIME types for .dll, .wasm, .blat, .dat, .json, etc.
   • SPA fallback routing (index.html fallback).
   • Correct caching headers for Blazor’s immutable assets.

3. Support for Multi-Project .NET Solutions
   • Allow selecting which project inside a GitHub repository should be built and deployed.
   • Useful for solutions containing:
   • API
   • Blazor WASM
   • Background workers
   • Shared libraries
   • A configuration option like “Path to project file” would fully solve this.

4. WASM Tools Installation
   • Add an option to install .NET wasm-tools workload before building:

dotnet workload install wasm-tools

•	This is required for all Blazor WebAssembly builds.

Describe alternatives you've considered

•	Manually editing Dockerfiles to install workloads and configure static file hosting — but this defeats the purpose of using Dokploy’s built-in deployment system.
•	Splitting a multi-project solution into multiple repositories — not practical and breaks common .NET architecture patterns.
•	Using a custom Nginx container for static Blazor hosting — works, but requires too much manual configuration for Brotli/Gzip, routing, MIME types, and is not integrated with Dokploy build pipelines.

Additional context

No response

Will you send a PR to implement it?

No

Start by tracing Dokploy’s GitHub integration and built-in build pipelines, then review how Dockerfiles and custom Nginx hosting are currently handled. The requested work spans .NET 10 builds, wasm-tools installation, multi-project selection, and Blazor static hosting; done means all four areas work without the listed manual workarounds.