Use MSBuild SDK Resolvers #974
Conversation
With the SDK Resolvers included in OmniSharp, we no longer need to set the MSBuildSDKsPath environment variable for each project. Instead, the SDK Resolvers should do that work. For tests, we now ensure that MSBuild is always initialized in standalone mode and we set the MSBuildSDKsPath environement variable specifically to ensure that the .NET Core SDK(s) downloaded by the OmniSharp build are used in tests.
DustinCampbell
changed the title
|
I just tested on OSX when Mono is installed and when it isn't, and it's working after a small bug fix. I also updated the Mono runtime and MSBuild to newer builds. This is good for review now. |
|
| } | ||
| else if (Platform.Current.IsLinux) | ||
| { | ||
| CopyDotNetHostResolver(env, "linux", "x64", "libhostfxr.so", msbuildSdkResolverFolder, copyToArchSpecificFolder: false); |
There was a problem hiding this comment.
Is the lack of linux-x86 no longer an issue for you?
There was a problem hiding this comment.
I realized that it's kind of a non-issue since .NET Core isn't supported on linux-x86 anyway. Since I can't install a .NET Core SDK on linux-x86, I can't see a need to resolve to it on linux-x86. 😄
|
Thanks! |
| @@ -4,6 +4,6 @@ | |||
| <clear /> | |||
| <add key="NuGet" value="https://api.nuget.org/v3/index.json" /> | |||
| <add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" /> | |||
| <add key="cli-deps" value="https://dotnet.myget.org/F/cli-deps/api/v3/index.json" /> | |||
There was a problem hiding this comment.
Awesome, we actually want to terminate the cli-deps feed, since it was actually built to contain all the packages the CLI depends on, but we have moved away from that approach since then.
There was a problem hiding this comment.
Yeah, this was an old feed from long ago.
Currently, we launch
dotnet --infofor every MSBuild project. This allows us to detect the .NET Core SDK that is used for that project without having to replicate a lot of code to search for aglobal.json, or look in various places. Once we've have the output ofdotnet --info, we look for the "Base Path" property and use that to decide where the location of the "Sdks" are within the relevant .NET Core SDK's directory. Once we've got that, we set theMSBuildSDKsPathenvironment variable to tell MSBuild where the SDKs are before we load the project.This approach has several problems:
dotnet --infois fragile! The .NET Core SDK's informational output is subject to change, and there are proposals to do it.To avoid this problem, OmniSharp will deploy the same "SDK Resolvers" that are deployed with Visual Studio. This is a bit of code that knows how to resolve a project to the correct .NET Core SDK. In fact, it uses the same native binary that "dotnet" does to find the SDK. Once present, MSBuild uses the resolver to locate the .NET Core SDK for any project that contains an
Sdkattribute.For tests, we still set the
MSBuildSDKsPathenvironment variable so that we can use the .NET Core SDKs that the OmniSharp build scripts install locally during our test runs. We could write our own SDK Resolver to resolve our local .NET Core SDKs during testing, but that's probably overkill. If it becomes an issue, we can look into that.