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

[release/6.0-preview7] Update dependencies from dotnet/arcade #56235

Conversation

dotnet-maestro[bot]
Copy link
Contributor

This pull request updates the following dependencies

From https://github.com/dotnet/arcade

  • Subscription: 449fc7bd-f1b1-4109-5ad9-08d93c09849a
  • Build: 20210722.16
  • Date Produced: 7/22/2021 11:29 PM
  • Commit: 6224d1b573b73caaa84176bd83dabe75f202cdc7
  • Branch: refs/heads/main
  • Updates to .NET SDKs:
    • Updates sdk.version to 6.0.100-preview.6.21355.2
    • Updates tools.dotnet to 6.0.100-preview.6.21355.2

…722.16

Microsoft.DotNet.XUnitExtensions , Microsoft.DotNet.VersionTools.Tasks , Microsoft.DotNet.Build.Tasks.Workloads , Microsoft.DotNet.Build.Tasks.TargetFramework.Sdk , Microsoft.DotNet.Build.Tasks.Packaging , Microsoft.DotNet.Build.Tasks.Installers , Microsoft.DotNet.Build.Tasks.Feed , Microsoft.DotNet.Build.Tasks.Archives , Microsoft.DotNet.Arcade.Sdk , Microsoft.DotNet.ApiCompat , Microsoft.DotNet.CodeAnalysis , Microsoft.DotNet.XUnitConsoleRunner , Microsoft.DotNet.GenFacades , Microsoft.DotNet.GenAPI , Microsoft.DotNet.RemoteExecutor , Microsoft.DotNet.PackageTesting , Microsoft.DotNet.Helix.Sdk , Microsoft.DotNet.SharedFramework.Sdk
 From Version 6.0.0-beta.21364.3 -> To Version 6.0.0-beta.21372.16
@dotnet-issue-labeler
Copy link

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.

@mmitche
Copy link
Member

mmitche commented Jul 23, 2021

@joeloff Can you take a look at this?

@joeloff
Copy link
Member

joeloff commented Jul 23, 2021

Looks like an issue with retrieving some packages

##[error].dotnet\sdk\6.0.100-preview.6.21355.2\NuGet.RestoreEx.targets(19,5): error : (NETCORE_ENGINEERING_TELEMETRY=Restore) Failed to retrieve information about 'System.IO.MemoryMappedFiles' from remote source 'https://pkgs.dev.azure.com/dnceng/9ee6d478-d288-47f7-aacc-f6e6d082ae6d/_packaging/1a5f89f6-d8da-4080-b15f-242650c914a8/nuget/v3/flat2/system.io.memorymappedfiles/index.json'.

Doesn't appear to be related to the Arcade update.

@lewing
Copy link
Member

lewing commented Jul 23, 2021

bumping the sdk is going to need the changes from #55283

* 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>
@mmitche
Copy link
Member

mmitche commented Jul 23, 2021

bumping the sdk is going to need the changes from #55283

Cherry-picked those changes.

@mmitche mmitche closed this Jul 23, 2021
@dotnet-maestro dotnet-maestro bot deleted the darc-release/6.0-preview7-9079d833-2fa5-4698-848c-09459fb9dc00 branch July 23, 2021 22:20
@danmoseley danmoseley added the area-codeflow for labeling automated codeflow label Jul 28, 2021
@ghost ghost locked as resolved and limited conversation to collaborators Aug 27, 2021
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-codeflow for labeling automated codeflow
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants