Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add runtimeconfig.json support for WebAssembly #56486

Merged
merged 29 commits into from
Aug 6, 2021

Conversation

fanyang-mono
Copy link
Member

@fanyang-mono fanyang-mono commented Jul 28, 2021

Added runtimeconfig.json support for WebAssembly.
Fixes #38433

Added a test for it.
Fixes #50908

Also added a test to Wasm.Build.Tests, thanks to @radical

@fanyang-mono fanyang-mono added the arch-wasm WebAssembly architecture label Jul 28, 2021
@ghost
Copy link

ghost commented Jul 28, 2021

Tagging subscribers to 'arch-wasm': @lewing
See info in area-owners.md if you want to be subscribed.

Issue Details

Fixes #38433

Author: fanyang-mono
Assignees: -
Labels:

arch-wasm

Milestone: -

@fanyang-mono fanyang-mono marked this pull request as ready for review July 28, 2021 19:17
@radical radical added this to the 6.0.0 milestone Jul 28, 2021
Copy link
Member

@lambdageek lambdageek left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The embedding changes LGTM. There's a couple of unnecessary things copied over from the hot reload functional test that I don't think you need.

Not sure about the Wasm infrastructure changes. @radekdoulik or @radical could oyu review those?

src/mono/wasm/build/WasmApp.InTree.targets Outdated Show resolved Hide resolved
src/mono/wasm/build/WasmApp.LocalBuild.targets Outdated Show resolved Hide resolved
src/mono/wasm/build/WasmApp.targets Outdated Show resolved Hide resolved
src/mono/wasm/build/WasmApp.targets Outdated Show resolved Hide resolved
src/mono/wasm/build/WasmApp.targets Outdated Show resolved Hide resolved
src/mono/wasm/build/WasmApp.LocalBuild.props Show resolved Hide resolved
src/mono/wasm/build/WasmApp.targets Outdated Show resolved Hide resolved
@radical
Copy link
Member

radical commented Jul 29, 2021

Does this PR mean that setting environment variables like this would work? If so, then that should be included in the Wasm.Build.Tests test being added for runtimeconfig.

@radical
Copy link
Member

radical commented Jul 29, 2021

Not for this PR, but we maybe need to handle the case when you have

{
   "runtimeOptions": {
      "configProperties": {
         "System.Globalization.Invariant": true
      }
   }
}

.. in your runtimeconfig.template.json, then the wasm targets should treat this as $(InvariantGlobalization)=true. @lewing ?

@fanyang-mono
Copy link
Member Author

Not for this PR, but we maybe need to handle the case when you have

{
   "runtimeOptions": {
      "configProperties": {
         "System.Globalization.Invariant": true
      }
   }
}

.. in your runtimeconfig.template.json, then the wasm targets should treat this as $(InvariantGlobalization)=true. @lewing ?

My runtimeconfig.template.json is only valid for the test I added. It needs to be added for the app who needs the configuration of $(InvariantGlobalization)=true. To my understanding, runtimeconfig.template.json needs to be visible during the build/publish process.

@lambdageek
Copy link
Member

lambdageek commented Jul 30, 2021

Not for this PR, but we maybe need to handle the case when you have

{
   "runtimeOptions": {
      "configProperties": {
         "System.Globalization.Invariant": true
      }
   }
}

.. in your runtimeconfig.template.json, then the wasm targets should treat this as $(InvariantGlobalization)=true. @lewing ?

runtime.template.json is meant to configure the runtime behavior of the app, not how it is built/packaged. Using it to configure the build doesn't make a lot of sense to me.

@radical
Copy link
Member

radical commented Jul 30, 2021

runtime.template.json is meant to configure the runtime behavior of the app, not how it is built/packaged. Using it to configure the build doesn't make a lot of sense to me.

What happens if you only set the "System.Globalization.Invariant": true in your runtimeconfig.template.json, in a non-wasm project? Is that the equivalent to using /p:InvariantGlobalization=true?

If so, then in case of wasm, we need to link out relevant bits, IIUC, and for that wasm targets would need to read the config file.

Copy link
Member

@lewing lewing left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a good start but doesn't look like it will work in blazor apps

src/mono/wasm/build/WasmApp.targets Show resolved Hide resolved
@fanyang-mono
Copy link
Member Author

Lane dotnet-linker-tests (Build windows x64 release Runtime_Release) actually passed for rerun. Don't know why it still showed up as failed. https://dev.azure.com/dnceng/public/_build/results?buildId=1272100&view=results

@fanyang-mono
Copy link
Member Author

@radical @lewing If this change looks good to you, could you please approve it?

@radical radical self-requested a review August 3, 2021 21:00
@radical
Copy link
Member

radical commented Aug 3, 2021

There are some disabled tests with ActiveIssue on #38433 being fixed here, which should be enabled in this PR.

Copy link
Member

@radical radical left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good, just couple of comments

src/mono/wasm/build/WasmApp.targets Outdated Show resolved Hide resolved
src/mono/wasm/build/WasmApp.targets Outdated Show resolved Hide resolved
fanyang-mono and others added 4 commits August 5, 2021 20:02
This fixes the build for ApplyUpdateReferencedAssembly.csproj, which is
a support project for HotReload wasm functional test.

```
D:\workspace\_work\1\s\src\mono\wasm\build\WasmApp.targets(131,5): error : Could not find
    D:\workspace\_work\1\s\artifacts\bin\ApplyUpdateReferencedAssembly\net6.0-Release\browser-wasm\publish\ApplyUpdateReferencedAssembly.runtimeconfig.json
    for D:\workspace\_work\1\s\artifacts\bin\ApplyUpdateReferencedAssembly\net6.0-Release\browser-wasm\publish\ApplyUpdateReferencedAssembly.dll.

    [D:\workspace\_work\1\s\src\tests\FunctionalTests\WebAssembly\Browser\HotReload\ApplyUpdateReferencedAssembly\ApplyUpdateReferencedAssembly.csproj]
```

The wasm targets should be run at all for this project. But they are run
because they get imported by tests.wasm.targets, which gets imported because
`$(IsTestProject)=true`.

The csproj has `$(IsTestProject)=false`, and `$(IsTestSupportProject)=true`,
which should mean that the test.props/targets don't get imported. But the
import is conditioned on `$(EnableTestSupport)`, which gets set in
`src/libraries/Directory.Build.props`. And that means setting
`$(IsTestProject)=true` in the csproj is too late.

So, instead, set that in a `Directory.Build.props`. And also, ensure that the
`Directory.Build.props` for functional tests doesn't override the value!
@radical radical self-requested a review August 6, 2021 05:01
Copy link
Member

@radical radical left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM, thanks for your patience! 👍

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
arch-wasm WebAssembly architecture area-VM-meta-mono
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add a runtimeconfig.json test for WASM WebAssembly should support handling runtimeconfig.json
4 participants