Update SDK to 6.0 Preview 5 #55283
Merged
Update SDK to 6.0 Preview 5 #55283
Conversation
This file contains 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
Part of #55281
ViktorHofer
added
NO-MERGE
|
Tagging subscribers to this area: @dotnet/runtime-infrastructure Issue DetailsPart of #55281
|
This was referenced Jul 8, 2021
Anipik
removed
the
NO-MERGE
|
@jkotas @LakshanF @agocke @vitek-karas - The trimming test failures on Windows appear to be a bad bug with trimmed coreclr apps. ErrorComparing working to non-workingIn the "working" version, CoreLib contains the DispatchWrapper class. In the "non-working" version, DispatchWrapper is gone. Change that caused itIn Preview5, we are setting more feature switches by default, specifically we are defaulting I'm opening an issue for this now. |
|
I've opened #55600 for the windows trimming failures. The tests caught a bug in our product. |
|
@eerhardt can we turn off this feature in order to unblock this pr ? |
One quick way to do that is to set runtime/eng/testing/linker/project.csproj.template Lines 14 to 18 in 14854e2 |
|
Yes, this seems like a good solution to unblock the infra change. |
safern
reviewed
Jul 15, 2021
|
hmm, now newtonsoft is missing? |
|
The dotnet-linker-tests wasm leg is failing due to: @lewing @radical @SamMonoRT - any thoughts? Why would this error start happening by upgrading the SDK from preview4 to preview5? Looks like it isn't just the trimming tests, I see it on the other wasm legs: |
|
Yes. This is likely going to be tricky. |
|
cc @radekdoulik |
For in-tree builds, and tests we don't want to use workloads from dotnet being used to build these. For the projects being built on the build machine, we can disable them via `Directory.Build.props`, and wasm's InTree/LocalBuild props. But for projects that get built on helix, eg. the runtime tests, we are setting the property values as environment variables.
|
Hopefully, this will fix the breakage. |
|
@agocke @vitek-karas - the installer host model tests are now failing:
|
eerhardt
reviewed
Jul 18, 2021
| @@ -15,6 +15,8 @@ | |||
| <TargetingPackDir>{TargetingPackDir}</TargetingPackDir> | |||
| <NETCoreAppMaximumVersion>{NetCoreAppMaximumVersion}</NETCoreAppMaximumVersion> | |||
| <MicrosoftNETCoreAppVersion>{MicrosoftNETCoreAppVersion}</MicrosoftNETCoreAppVersion> | |||
| <!-- Workaround issue: https://github.com/dotnet/runtime/issues/55600 --> | |||
| <BuiltInComInteropSupport>true</BuiltInComInteropSupport> | |||
There was a problem hiding this comment.
This can be reverted now that #55756 is merged.
In preview5, the workload manifest overrides
`$(UsingBrowserRuntimeWorkload)` setting, so pass it on the command
line.
``xml
<PropertyGroup Condition="'$(RuntimeIdentifier)' == 'browser-wasm'">
<UsingBrowserRuntimeWorkload Condition="'$(RunAOTCompilation)' == 'true' or '$(UsingMicrosoftNETSdkBlazorWebAssembly)' != 'true'" >true</UsingBrowserRuntimeWorkload>
<UsingBrowserRuntimeWorkload Condition="'$(UsingBrowserRuntimeWorkload)' == ''" >$(WasmNativeWorkload)</UsingBrowserRuntimeWorkload>
</PropertyGroup>
```
In P5 we don't generate .runtimeconfig.dev.json anymore. Some tests started to fail because they relied on the .runtime.dev.json to include local nuget cache in the probing paths. I changed one of those tests to force-generate .runtimeconfig.dev.json as for the tested scenario it seems to make sense. For the other test I modified it to copy the necessary dependency into the right location instead.
|
I have a fix for the host tests here: https://github.com/vitek-karas/runtime/tree/FixHostTests. |
|
Wasm/windows:
@radekdoulik any idea about why this might be timing out?
|
eerhardt
reviewed
Jul 21, 2021
|
Known Failure #55999 |
Anipik
approved these changes
Jul 22, 2021
mmitche
pushed a commit
that referenced
this pull request
Jul 23, 2021
* Update SDK to 6.0 Preview 6 Part of #55281 * Enable COM support to work around missing symbols in tests * Update eng/testing/linker/project.csproj.template * Disable the workload targets * Disable workloads for wasm builds For in-tree builds, and tests we don't want to use workloads from dotnet being used to build these. For the projects being built on the build machine, we can disable them via `Directory.Build.props`, and wasm's InTree/LocalBuild props. But for projects that get built on helix, eg. the runtime tests, we are setting the property values as environment variables. * Fix setting envvars for disabling workloads * Another attempt to fix wasm tests In preview5, the workload manifest overrides `$(UsingBrowserRuntimeWorkload)` setting, so pass it on the command line. ``xml <PropertyGroup Condition="'$(RuntimeIdentifier)' == 'browser-wasm'"> <UsingBrowserRuntimeWorkload Condition="'$(RunAOTCompilation)' == 'true' or '$(UsingMicrosoftNETSdkBlazorWebAssembly)' != 'true'" >true</UsingBrowserRuntimeWorkload> <UsingBrowserRuntimeWorkload Condition="'$(UsingBrowserRuntimeWorkload)' == ''" >$(WasmNativeWorkload)</UsingBrowserRuntimeWorkload> </PropertyGroup> ``` * Fix host tests after upgrade to P5 In P5 we don't generate .runtimeconfig.dev.json anymore. Some tests started to fail because they relied on the .runtime.dev.json to include local nuget cache in the probing paths. I changed one of those tests to force-generate .runtimeconfig.dev.json as for the tested scenario it seems to make sense. For the other test I modified it to copy the necessary dependency into the right location instead. * Fix up reflection to private FileStatus field * Disable workload resolver for wasm.build.tests, EMSDK run * Disable workloads for wasm with MSBuildEnableWorkloadResolver=false everywhere * remove linker workaround * [wasm] Remove args unnecessary for disabling workloads * Pass MSBuildEnableWorkloadResolver property to individual trimming projects Co-authored-by: Juan Sebastian Hoyos Ayala <juhoyosa@microsoft.com> Co-authored-by: Santiago Fernandez Madero <safern@microsoft.com> Co-authored-by: Larry Ewing <lewing@microsoft.com> Co-authored-by: Ankit Jain <radical@gmail.com> Co-authored-by: vitek-karas <vitek.karas@microsoft.com> Co-authored-by: Eric Erhardt <eric.erhardt@microsoft.com> Co-authored-by: Anirudh Agnihotry <anirudhagnihotry098@gmail.com>
ghost
locked as resolved and limited conversation to collaborators
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
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.
Part of #55281