It looks like how Razor Class Library works now can cause issues when hosting multiple Blazor applications.
Blazor app should be independent from each other. And its assets should not interfere with assets of other applications. However, if several applications reference different versions of same Razor Class Library with changed assets, this can cause pain because RCL assets folder _content/LibName does not contain version.
When I publish my ASP.NET Core application, I get these folders in wwwroot:
BlazorLib
styles.css
Client1
Client2
I use StaticWebAssetBasePath for each app project.
And I reference lib assets in index.html this way:
<base href="/Client1/" />
<link href="../_content/BlazorLib/styles.css" rel="stylesheet" />
Another potential issue is the need to refrence Blazor projects from ASP.NET Core hosting application. If each of the projects uses same NuGet package with different versions this may cause inadvertent version change of the used dependency for the hosting app. This is also valid when hosting just one Blazor app.
@voroninp thanks for contacting us.
We are aware that this is a current limitation. However, if you currently reference different versions of a package you are going to have version problems with the dlls referenced by that package.
Even if we were to completely isolate each app, it would still be impossible to support some things like prerendering.
We might consider revisiting this if we hear more feedback about it, but at the moment is not very high on our priority list, since we've haven't seen many asks for it and it requires a lot of work on our part.
We've moved this issue to the Backlog milestone. This means that it is not going to happen for the coming release. We will reassess the backlog following the current release and consider this item at that time. However, keep in mind that there are many other high priority features with which it will be competing for resources.
@javiercn I agree, this likely won't be an issue for 99.99% of use cases. It is just how I usually approach new tech. I start looking at corner cases - this gives me a better understanding of how things work under the hood.
@javiercn I have a multi-blazor POC loosely based upon your version; BlazorMultipleApps.
From what I am seeing, there should not be dll version conflicts if my hosting server app is simply referencing client-only projects like FirstApp and SecondApp.
There is no such thing as sharing libs between client wasms and the hosting server.
My only requirement is that these get published correctly.
From what I can see, everything in my SecondApp correctly publishes the dependant DLLs in publish/wwwroot/SecondApp/_framework/_bin/{{bunch of dlls}}
I then reference BlazorPro.SpinKit in my SecondApp project. I correctly see all the BlazorPro.Spinkit.dll(s) in the publish/wwwroot/SecondApp/_framework/_bin/{{bunch of dlls}}
What I don't see correctly happening is that the static content that BlazorPro.Spinkit has is stuck in.
publish/wwwroot/_content/BlazorPro.Spinkit/spinkit.min.css
Is there a workaround I can do to make sure that the BlazorPro.Spinkit static content is published in the following location;
/publish/wwwroot/SecondApp/_content/BlazorPro.Spinkit/spinkit.min.css
./bin/Release/netstandard2.1/publish/wwwroot./bin/Release/netstandard2.1/publish/wwwroot/_content -> {{blazorapp}}/wwwroot/_contentinclude in project the newly copied _content folder. @javiercn Can you clarify the following;
given 2 client-side apps; FirstApp and SecondAdd. Both appear to have their dlls isolated in publish when you use the;
<StaticWebAssetBasePath>SecondApp</StaticWebAssetBasePath>
directive the the csproj.
Are they still isolated when I toggle between them client-side? i.e. no binary collisions, no overwrites, etc.
I haven't tried this yet, but can I host 2 separate apps in the same index.html and be assured that there is binary isolation? Again no binary collisions, no overwrites, just harmony.
Most helpful comment
@voroninp thanks for contacting us.
We are aware that this is a current limitation. However, if you currently reference different versions of a package you are going to have version problems with the dlls referenced by that package.
Even if we were to completely isolate each app, it would still be impossible to support some things like prerendering.
We might consider revisiting this if we hear more feedback about it, but at the moment is not very high on our priority list, since we've haven't seen many asks for it and it requires a lot of work on our part.