Hot Reload: test on WebAssembly #53050
Conversation
1. Always build the assemblies in the ApplyUpdate/ subdirectory without optimization, with debug info. Hot reload depends on it. 2. Pass the required environment variable to the runtime via xharness to enable support for applying updates.
|
I couldn't figure out the best area label to add to this PR. If you have write-permissions please help me learn by adding exactly one area label. |
| <Target Name="IncludeDeltasInWasmBundle" | ||
| BeforeTargets="PrepareForWasmBuildApp" | ||
| Condition="'$(TargetOS)' == 'Browser'"> | ||
| <ItemGroup> | ||
| <!-- FIXME: this belongs in eng/testing/tests.wasm.targets --> | ||
| <!-- FIXME: Can we do something on the Content items in the referenced projects themselves to get this for free? --> | ||
| <WasmFilesToIncludeInFileSystem Include="@(PublishItemsOutputGroupOutputs)" | ||
| Condition="$([System.String]::new('%(PublishItemsOutputGroupOutputs.Identity)').EndsWith('.dmeta'))" /> | ||
| <WasmFilesToIncludeInFileSystem Include="@(PublishItemsOutputGroupOutputs)" | ||
| Condition="$([System.String]::new('%(PublishItemsOutputGroupOutputs.Identity)').EndsWith('.dil'))" /> | ||
| <WasmFilesToIncludeInFileSystem Include="@(PublishItemsOutputGroupOutputs)" | ||
| Condition="$([System.String]::new('%(PublishItemsOutputGroupOutputs.Identity)').EndsWith('.dpdb'))" /> | ||
| </ItemGroup> |
There was a problem hiding this comment.
@radical help! I don't like how I did this. For some reason the <Content> that my referenced projects are creating (using the hot reload build tool, below) don't get copied into the wasm filesystem.
I'm not looking forward to doing this for Android and iOS, too. Maybe there's some general metadata I can set on those items so the publish process will put them in the right place in the wasm app bundle? (They're loaded using File.ReadAllBytes so putting them in \supportFiles actually works out. Just wish they'd get there automatically)
There was a problem hiding this comment.
IIUC:
-
@(Content)is added in project (*ApplyUpdate*), and the main test project references that -
tests.wasm.targetsadds@(ContentWithTargetPath)to the wasm vfs- but that gets populated only by the
@(Content)items from the test project itself - Out of all full set of copy-local items from referenced projects, I couldn't figure out a way to differentiate the ones that came from
@(Content)[1] - it wouldn't make sense to add all the copy-local files to the vfs though!
- but that gets populated only by the
-
It would be nice to have some idiom for what gets automatically added to the vfs, and maybe
WasmApp.targetscan use that -
Maybe, XI/XA have a solution for this? @rolfbjarne @jonathanpeppers
-
Otherwise, I think, at least for now, your approach is fine 😬
--
- um there is a property that would allow retaining the original metadata from the
Content, so that could be helpful here, but it sounds hacky!
There was a problem hiding this comment.
um there is a property that would allow retaining the original metadata from the
Content, so that could be helpful here, but it sounds hacky!
To be honest filtering by metadata sounds better to me than going by file extensions.
If I put DeltaOutputType metadata on the Content in the references (it's already there on the _HotReloadDeltaGeneratorOutputs, but I forgot to tack on the KeepMetadata thing), then, hopefully, that will propagate to the parent project's PublishItemsOutputGroupOutputs?
And then I would feel less bad about adding them to WasmFilesToIncludeInFileSystem in eng/testing/tests.wasm.targets.
There was a problem hiding this comment.
On Android we don't actually use @(Content) at all and emit warnings. This is just because of the way .apk files are compressed on disk, we can't put a file somewhere where File.Open() would even work.
You might be able to do something like this to grab files from all @(ProjectReference), though:
<MSBuild Projects="@(ProjectReference)" Targets="HotReloadDeltaGeneratorContentForOutputs">
<Output TaskParameter="TargetOutputs" ItemName="_ContentFromProjectReference" />
</MSBuild>Not sure if that helps or not.
There was a problem hiding this comment.
I'm not quite sure I understand what you need to do. It seems that you're trying to build an app that contains both the original assemblies + the modified assemblies that should be loaded through hot reload, and then those modified assemblies should be in a specific location within the app bundle, is that right?
|
Tagging subscribers to this area: @tannergooding Issue Details
|
|
/cc @mikem8361 for the hot reload tests, the assemblies that will be modified are now always compiled with debug info. Don't think this will affect anything for CoreCLR testing, but just a heads up. |
|
The |
|
|
ghost
locked as resolved and limited conversation to collaborators
optimization, with debug info. Hot reload depends on it.
support for applying updates.