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

Fix bug mixing .NET SDKs #73

Merged
merged 1 commit into from
Nov 10, 2023
Merged

Fix bug mixing .NET SDKs #73

merged 1 commit into from
Nov 10, 2023

Conversation

jaredpar
Copy link
Owner

@jaredpar jaredpar commented Nov 9, 2023

My home box has both the 7.0.400 and 8.0.100 RC2 .NET SDKs installed. This ended up revealing a subtle bug in the CLI when executing dotnet test.

The test content in this repo generates a global.json that pins the SDK to 7.0.400. That is done for consistency in testing across developer machines and CI. The repository itself has no global.json file so it floats to the latest .NET SDK.

This combination revealed an odd bug in MSBuild. When executing dotnet test the CLI ended up spawning a dotnet that sets the %MSBuildSDKsPath% environment variable. Because dotnet spawned as an 8.0 process it set that path to the 8.0 SDK.

When executing the dotnet new actions inside the tests the global.json was read by the runtime host and ended up spawning a dotnet process from the 7.0 runtime. But msbuild ended up loading tasks / targets from 8.0 SDK due to the %MSBuildSDKsPath% value. Those targeted net8.0
and hence failed to load in the 7.0 runtime.

The template "Console App" was created successfully.

 Processing post-creation actions...
 Restoring
 C:\Users\jaredpar\AppData\Local\Temp\CompilerLogFixture\be3521749f1e49c8bb93b2212110c4a8\scratch
 dir\0aa90c51a9794319bb0d1370e52350dc\example-no-generator.csproj:
   Determining projects to restore...
   C:\Program
   Files\dotnet\sdk\8.0.100-rc.2.23502.2\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.Shared.targets(152,5):
   error MSB4062: The "CheckForImplicitPackageReferenceOverrides" task
   could not be loaded from the assembly C:\Program
   Files\dotnet\sdk\8.0.100-rc.2.23502.2\Sdks\Microsoft.NET.Sdk\targets\..\tools\net8.0\Microsoft.NET.Build.Tasks.dll.
   Could not load file or assembly 'System.Runtime, Version=8.0.0.0,
   Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot
   find the file specified. Confirm that the <UsingTask> declaration is
   correct, that the assembly and all its dependencies are available,
   and that the task contains a public class that implements
   Microsoft.Build.Framework.ITask.
   [C:\Users\jaredpar\AppData\Local\Temp\CompilerLogFixture\be3521749f1e49c8bb93b2212110c4a8\scratch
   dir\0aa90c51a9794319bb0d1370e52350dc\example-no-generator.csproj]

Thanks to @rainersigwald and @baronfel for tracking this down!

dotnet/msbuild#9411

variable

My home box has both the 7.0.400 and 8.0.100 RC2 .NET SDKs installed.
This ended up revealing a subtle bug in the CLI when executing `dotnet
test`.

The test content in this repo generates a global.json that pins the SDK
to 7.0.400. That is done for consistency in testing across developer
machines and CI. The repository itself has no global.json file so it
floats to the _latest_ .NET SDK.

This combination revealed an odd bug in MSBuild. When executing `dotnet
test` the CLI ended up spawning a `dotnet` that sets the
`%MSBuildSDKsPath%` environment variable. Because `dotnet` spawned as an
8.0 process it set that path to the 8.0 SDK.

When executing the `dotnet new` actions inside the tests the global.json
was read by the runtime host and ended up spawning a `dotnet` process
from the 7.0 runtime. But msbuild ended up loading tasks / targets from
8.0 SDK due to the `%MSBuildSDKsPath%` value. Those targeted `net8.0`
  and hence failed to load in the 7.0 runtime.

```
The template "Console App" was created successfully.

 Processing post-creation actions...
 Restoring
 C:\Users\jaredpar\AppData\Local\Temp\CompilerLogFixture\be3521749f1e49c8bb93b2212110c4a8\scratch
 dir\0aa90c51a9794319bb0d1370e52350dc\example-no-generator.csproj:
   Determining projects to restore...
   C:\Program
   Files\dotnet\sdk\8.0.100-rc.2.23502.2\Sdks\Microsoft.NET.Sdk\targets\Microsoft.NET.Sdk.DefaultItems.Shared.targets(152,5):
   error MSB4062: The "CheckForImplicitPackageReferenceOverrides" task
   could not be loaded from the assembly C:\Program
   Files\dotnet\sdk\8.0.100-rc.2.23502.2\Sdks\Microsoft.NET.Sdk\targets\..\tools\net8.0\Microsoft.NET.Build.Tasks.dll.
   Could not load file or assembly 'System.Runtime, Version=8.0.0.0,
   Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. The system cannot
   find the file specified. Confirm that the <UsingTask> declaration is
   correct, that the assembly and all its dependencies are available,
   and that the task contains a public class that implements
   Microsoft.Build.Framework.ITask.
   [C:\Users\jaredpar\AppData\Local\Temp\CompilerLogFixture\be3521749f1e49c8bb93b2212110c4a8\scratch
   dir\0aa90c51a9794319bb0d1370e52350dc\example-no-generator.csproj]
```

Thanks to @rainersigwald and @baronfel for tracking this down!

dotnet/msbuild#9411

variable
@jaredpar jaredpar merged commit 8170b0d into main Nov 10, 2023
2 checks passed
@jaredpar jaredpar deleted the bug branch November 10, 2023 14:05
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants