System.Private.CoreLib.csproj fails to load in System.Private.CoreLib.sln without global installations of nightly/preview SDK

[Gnbrkm41]

The project fails to load with the log Project "C:\users\gotos\source\repos\runtime\src\coreclr\src\System.Private.CoreLib\codeOptimization.targets" was not imported by "C:\users\gotos\source\repos\runtime\src\coreclr\src\System.Private.CoreLib\System.Private.CoreLib.csproj" at (401,3), due to the file not existing.. This is after building Clr+Libs subset successfully, via build -subset Clr+Libs -runtimeConfig Release on a clean repo.

The said codeOptimization.targets file indeed does not seem to exist in the specified folder.

[danmoseley]

C:\git\runtime\src\coreclr\src\System.Private.CoreLib\System.Private.CoreLib.csproj:
  401:   <Import Project="$(RepositoryEngineeringDir)codeOptimization.targets" />

This means $(RepositoryEngineeringDir) is not getting set. Which apparently should happen here:

C:\git\runtime\Directory.Build.props:
   22    <PropertyGroup Condition="'$(SkipImportArcadeSdkFromRoot)' == 'true'">
   23      <RepoRoot>$([MSBuild]::EnsureTrailingSlash('$(MSBuildThisFileDirectory)'))</RepoRoot>
   24:     <RepositoryEngineeringDir>$([MSBuild]::NormalizeDirectory('$(RepoRoot)', 'eng'))</RepositoryEngineeringDir>

I don't know what '$(SkipImportArcadeSdkFromRoot)' == 'true' is about. But it's apparently set here

C:\git\runtime\src\coreclr\Directory.Build.props:
    2  
    3    <PropertyGroup>
    4:     <SkipImportArcadeSdkFromRoot>true</SkipImportArcadeSdkFromRoot>

@ViktorHofer ?

[ViktorHofer]

Just tried to repro this locally without success. The project both loads and builds successfully for me.

The said codeOptimization.targets file indeed does not seem to exist in the specified folder.

You mean on your local enlistment, this file is missing from the root eng folder?

I don't know what '$(SkipImportArcadeSdkFromRoot)' == 'true' is about. But it's apparently set here

This property determines if the Arcade SDK should be imported in the root's Directory.Build.props/targets files.

[Gnbrkm41]

You mean on your local enlistment, this file is missing from the root eng folder?

For some reason, it seems to look for the file from the solution root (src\coreclr\src\System.Private.CoreLib\codeOptimization.targets).

I am not the only one having this problem; @KoziLord was having this problem yesterday too.

[ViktorHofer]

Can you please send me a design time binlog by capturing the loading of the project? https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.ProjectSystemTools

[Gnbrkm41]

I have installed the extension, but I am not sure how I am supposed to use it; I opened the Build logging windows and have the build logging started but it doesn't seem to actually have any design time build related logs.

[Gnbrkm41]

Actually... this is the full log that's being shown when I try to load the project:

C:\Users\gotos\source\repos\runtime\src\coreclr\src\System.Private.CoreLib\System.Private.CoreLib.csproj : error  : The project file cannot be opened by the project system, because it is missing some critical imports or the referenced SDK cannot be found.

Detailed Information:
Unable to locate the .NET Core SDK. Check that it is installed and that the version specified in global.json (if any) matches the installed version.

Project "C:\System.Private.CoreLib\src\System.Private.CoreLib.Shared.projitems" was not imported by "C:\Users\gotos\source\repos\runtime\src\coreclr\src\System.Private.CoreLib\System.Private.CoreLib.csproj" at (384,3), due to the file not existing.

Project "C:\Users\gotos\source\repos\runtime\src\coreclr\src\System.Private.CoreLib\codeOptimization.targets" was not imported by "C:\Users\gotos\source\repos\runtime\src\coreclr\src\System.Private.CoreLib\System.Private.CoreLib.csproj" at (401,3), due to the file not existing.

Could it be because of the SDK missing? and if so why does it think it is missing, when it's clearly inside the .dotnet folder?

[ViktorHofer]

When you open a project inside VS, the globally installed SDK is used. Ideally we would want VS to tell to not use that one but there is currently no hook to do so.

The minimum required SDK version is specified here: https://github.com/dotnet/runtime/blob/master/global.json#L3. This is documented here: https://github.com/dotnet/runtime/blob/master/docs/workflow/requirements/windows-requirements.md#net-sdk. You can find the download links for the required SDK version here: https://github.com/dotnet/installer#installers-and-binaries.

For Windows, https://aka.ms/dotnet/net5/preview5/Sdk/dotnet-sdk-win-x64.exe should suffice.

[Gnbrkm41]

Installing the SDK globally indeed solves the problem. 👍

I wish the document was updated to be more accurate about it though, for me it sounds like it's only necessary if you want to run and build apps via the normal dotnet way. It doesn't mention it's also required if you want to open solution files with VS... and I was not expecting this to happen because it "just worked" without global installations before (or could be that I had late enough SDK already globally installed).

P.S. the aka.ms link doesn't seem to work? I know the other links point to the same thing but >.>

[ViktorHofer]

and I was not expecting this to happen because it "just worked" without global installations before (or could be that I had late enough SDK already globally installed)

Yes that was probably the case. VS always used the globally installed SDK.

I wish the document was updated to be more accurate about it though, for me it sounds like it's only necessary if you want to run and build apps via the normal dotnet way. It doesn't mention it's also required if you want to open solution files with VS...

Great feedback :) Would you mind submitting a PR to make this clearer and correct the aka.ms link and point to https://github.com/dotnet/installer#installers-and-binaries instead?

[Gnbrkm41]

Would you mind submitting a PR to make this clearer

Could do 🙂

correct the aka.ms link

No, I meant the link at the end of your last comment didn't work...

[ViktorHofer]

No, I meant the link at the end of your last comment didn't work...

Oh I see. We just recently branched off for P5, that might be the reason. @dsplaisted are you aware of the dotnet/installer's P5 links not working correctly in the table? In example https://aka.ms/dotnet/net5/preview5/Sdk/dotnet-sdk-win-x64.exe.

Could do 🙂

Thanks :)

[dsplaisted]

@dsplaisted are you aware of the dotnet/installer's P5 links not working correctly in the table?

I think @bozturkMSFT and @wli3 are aware of this and working on it

[bekir-ozturk]

@dsplaisted We don't seem to have a P5 branch in dotnet/installer yet. Do we have that task assigned to someone?

[dsplaisted]

I think @sfoslund is the branch owner for preview 5.

[sfoslund]

It sounds like @mmitche will be handling setting up the preview branches.