[blazor] Set Cross-Origin-Policy headers for multi-threaded runtime

[maraf]

The multi-threaded runtime requires COP headers to enable SharedArrayBuffer in the browser.
In this PR we set them for

• all .js files under _framework directory
• fallback index.html

It changes only DevServer.

The runtime changes to enable threads in blazor are in the dotnet/runtime#85109

[maraf]

@javiercn I'm not sure if this is enough for hosted mode

[javiercn]

@maraf unfortunately no.

We'll have to find a solution for it. The best way to do it so far is to apply the changes in the app code directly, on the call to UseStaticFiles in hosted mode. From Blazor we are not going to intercept the static files middleware (we've done it in the past and causes mayhem)

[maraf]

@javiercn Do we want this change set for standalone mode?

[javiercn]

@maraf I think so, but we need to understand what consequences (if any) to the dev/deployment experience this has.

/cc: @SteveSandersonMS has thoughts in this space.

[javiercn]

Longer term I am hoping we can turn these headers dynamically based on configuration or a build time switch.

I didn't notice this is unconditional

[maraf]

I can move the changes around so they are valid only for devserver

[lambdageek]

Can the DevServer find out about the project build properties somehow? I don't think we want COP for arbitrary blazor projects. it could break someone's existing single threaded project, I think?

[maraf]

The last change works when the property is put in a csproj. It doesn't accept is passed as commnad-line argument

[maraf]

@radical Do you know if there is a way to "evaluate" properties passed as command-line arguments during dotnet run? The passed property has correct value during build, but when RunArguments evaluate, it ignores value from command-line

[ghost]

Looks like this PR hasn't been active for some time and the codebase could have been changed in the meantime.
To make sure no breaking changes are introduced, please leave an /azp run comment here to rerun the CI pipeline and confirm success before merging the change.

[pavelsavara]

Could we detect that the application has <WasmEnableThreads>true</WasmEnableThreads> in it and do it automatically ?

Should that parameter also do something to the published app's server ?

[maraf]

Detecting WasmEnableThreads=true doesn't work for RunArgumets when the property is passed as command-line argument dotnet/sdk#32551. Maybe we should store the information in runtimeConfig.

[pavelsavara]

I mean in the project file.

[maraf]

@javiercn @pavelsavara Do we want to take this approach? There is a bug in MSBuild property evaluation dotnet/sdk#32551 which breaks it when the property is passed as command-like argument. The issue is assigned and should get fixed. Anyway, I believe that the multi-threading will be almost always set in csproj.

[pavelsavara]

I prefer to make it work with WasmEnableThreads in the csproj as soon as possible.