Ensure ReadRequest type can be loaded on server. Fixes #26882 #26931
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
ghost
added
the
javiercn
approved these changes
Oct 15, 2020
Member
Author
|
CC @mkArtakMSFT This is the fix for #26882 which we should aim to include in 5.0. |
SteveSandersonMS
added
the
Servicing-consider
|
Hello human! Please make sure you've included the Shiproom Template in a comment or (preferably) the PR description. Also, make sure this PR is not marked as a draft and is ready-to-merge. |
pranavkm
approved these changes
Oct 15, 2020
mkArtakMSFT
added
Servicing-approved
Contributor
|
Thanks @SteveSandersonMS! |
dougbu
pushed a commit
that referenced
this pull request
Oct 27, 2020
dotnet-maestro bot
added a commit
that referenced
this pull request
Oct 27, 2020
[master] Update dependencies from dotnet/runtime dotnet/efcore - Update TFM net5.0 -> net6.0 - Introduce $(TargetTFM) - TargetTfm -> DefaultNetCoreTargetFramework - Updated: NETCoreAppMaximumVersion - Apply suggestions from code review Co-authored-by: Doug Bunting <[email protected]> - Fix version numbers used in Blazor WASM SDK - Address feedback from peer review - Fix check for platform version - Fix build config for dotnet-watch project - Update TFM net5.0 -> net6.0 - Introduce $(TargetTFM) - TargetTfm -> DefaultNetCoreTargetFramework - Apply suggestions from code review Co-authored-by: Doug Bunting <[email protected]> - Fix version numbers used in Blazor WASM SDK - Address feedback from peer review - Remove workaround in dotnet-watch tests - Testrunner to 5.0 and adding workarounds - Try props.in - net50 - Fixup KnownFrameworkReference for integration tests - Resolve a few comments - don't use repo-specific properties in shipping file - pass `$(DefaultNetCoreTargetFramework)` into template files used in tests - Update src/Components/WebAssembly/Sdk/src/targets/Microsoft.NET.Sdk.BlazorWebAssembly.Current.targets - Update KnownFrameworkReference for template tests - Use DefaultNetcoreTFM - Undo change to props.in - Update src/ProjectTemplates/test/ProjectTemplates.Tests.csproj - Update GenerateTestProps.targets - this is where `$(KnownAppHostPackOrFrameworkReferenceTfm)` is needed - Update src/ProjectTemplates/test/ProjectTemplates.Tests.csproj - additional template input not needed here - Other file changes - Rename the one net5.0 directory in the repo - Fixup rebase remnants - Use runtime and ref/ assemblies matching repo in Helix testing - add Directory.Build.*.in files based on project template test infrastructure - use files as import boundary where the project doesn't create its own Directory.Build.* files - ensure `dotnet-watch` tests also use the latest runtime and ref/ assemblies - Switch Directory.Build.*.in files in Helix content - ensure item manipulation is done after base items exist nit: Fix *.in exclusion - Update TFM workaround to reference 5.0 instead of 3.1 (#26991) - Make some Directory.Build.*.in settings override-able - that is, move some properties to Directory.Build.props.in also - fix `Condition`s that resulted in empty Directory.Build.targets - separate Directory.Build.empty.in - ensure RunTests project is _not_ affected by root Directory.Build.* files - Update SDK - Set `$(DefaultNetCoreTargetFramework)` in Helix root Directory.Build.props = `dotnet-watch` tests otherwise fail with "The TargetFramework value '' was not recognized" - Extend Helix Directory.Build.* workarounds - generate Directory.Build.* files when restoring any projects - include generated files in Helix runs needing the latest runtime - copy generated files when testing `dotnet-watch` locally - include generated content in Microsoft.NET.Sdk.BlazorWebAssembly.IntegrationTests test assets - remove duplicate settings from existing Directory.Build.* files - ensure shared framework and targeting packs are laid out under .dotnet/ before test assets restore - !fixup! Remove extra end tags - !fixup! Don't build GenerateFiles.csproj in desktop `msbuild` - !fixup! Arcade uses different test targets - Disable `crossgen` when building for Helix runs - make `$(CrossgenOutput)` property override-able - use override in CI jobs that submit to other platforms - for now, leave the ARM64 Helix jobs alone (build on Ubuntu, run in Debian) nits: - correct condition for `$(GenerateCrossgenProfilingSymbols)` - set `$(ASPNETCORE_TEST_LOG_DIR)` in every step of the Helix build jobs - Ensure ReadRequest type can be loaded on server. Fixes #26882 (#26931) - Enable debugging when using embedded PDBs (#27107) * Fix debug using embedded PDBs. * Check for either debugBuild or referenced PDBs Co-authored-by: Thays <[email protected]> - Ensure Blazor JS files are up-to-date - Merge branch 'master' into darc-master-76e24f4d-c90c-42ac-a1e5-411ae61ca37b
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #26882
Description
There's an
internaltype withinInputFilethat is only used when running on WebAssembly for an unmarshalled interop call. Since it's only used on WebAssembly, the struct layout assumed 32-bit.However we've now had two separate reports of scenarios where developers do things with reflection that walk through all the assembly's types in their test code. This results in trying to load the internal type on CoreCLR, which typically is 64-bit, and this triggers a type load exception and blocks test runs.
This is extremely easy to fix. We just change the struct layout to be compatible with 64-bit runtimes.
Customer impact
Unless fixed, customers whose code uses reflection to walk through all types in the
Microsoft.AspNetCore.Components.Webassembly will throw when running on a 64-bit runtime. Here's a customer report: #26882The other case where we saw this was in our own internal infrastructure.
Regression
No, it's new in 5.0.
Risk
The change is limited to
InputFile. It should not have any impact beyond that. It is theoretically possible that this change somehow breaksInputFilebut we have good E2E test coverage as well as manual verification. Also the change is so simple it's very easy to reason about.