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.

Sign up for GitHub

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

Jump to bottom

Fix DotnetSharedFrameworkTaskDir to not rely on DotnetBuildFromSource #8355

Merged
merged 1 commit into from
Jan 18, 2022
Merged

Fix DotnetSharedFrameworkTaskDir to not rely on DotnetBuildFromSource #8355

merged 1 commit into from
Jan 18, 2022

Commits on Jan 18, 2022

  1. Fix DotnetSharedFrameworkTaskDir to not rely on DotnetBuildFromSource 

    After dotnet#8338 we saw a build error in a dotnet/runtime build job that tries to validate source-build but still uses the non-source-built arcade packages:

```
 /__w/1/s/artifacts/source-build/self/src/src/libraries/ref.proj(68,5): error MSB4062: The "CreateFrameworkListFile" task could not be loaded from the assembly /__w/1/s/artifacts/source-build/self/package-cache/microsoft.dotnet.sharedframework.sdk/7.0.0-beta.22064.25/sdk/../tools/net6.0/Microsoft.DotNet.SharedFramework.Sdk.dll. Could not load file or assembly '/__w/1/s/artifacts/source-build/self/package-cache/microsoft.dotnet.sharedframework.sdk/7.0.0-beta.22064.25/tools/net6.0/Microsoft.DotNet.SharedFramework.Sdk.dll'. The system cannot find the file specified.
```

This is because the non-source-built arcade packages use netcoreapp3.1 libraries instead of  net6.0, but we're still setting DotnetBuildFromSource=true in those builds.

Instead of using DotnetBuildFromSource to switch between libraries we can check for the existence of the net6.0 folder which works in both scenarios.
    @akoeplinger
    akoeplinger committed Jan 18, 2022
    Configuration menu
    Copy the full SHA
    ae27fa6 View commit details
    Browse the repository at this point in the history