search

microsoft / MSBuildLocator

An API to locate MSBuild assemblies from an installed Visual Studio location. Use this to ensure that calling the MSBuild API will use the same toolset that a build from Visual Studio or msbuild.exe would.
Other
218 stars 83 forks source link

Return all installed DotNetSDK versions #79

Closed kurtcodemander closed 3 years ago

kurtcodemander commented 4 years ago

Returns a list of all installed dotnet SDKs as reported by dotnet --info instead of only the latest

msftclas commented 4 years ago

CLA assistant check
All CLA requirements met.

kurtcodemander commented 3 years ago

I have finally added another commit to this PR. I also added support for returning .NET 5.0 SDKs, which this PR did not previously have support for.

JoeRobich commented 3 years ago

So the current behavior is that for the current working directory you will get back the newest SDK or the one pinned in the global.json, I would prefer it if this behavior is retained when invoking MSBuildLocator.RegisterDefaults().

kurtcodemander commented 3 years ago

So the current behavior is that for the current working directory you will get back the newest SDK or the one pinned in the global.json, I would prefer it if this behavior is retained when invoking MSBuildLocator.RegisterDefaults().

It was suggested to use --list-sdks to populate the list of instances, which made sense to me, so that's what the latest commit contains, but it dawns on me that if there's one pinned in global.json then we'll probably have to use the "Base Path" from "dotnet --info" like before in order for the current behavior to be retained when invoking MSBuildLocator.RegisterDefaults().

With the behavior from the latest commit https://github.com/microsoft/MSBuildLocator/pull/79/commits/b6353cb6a96dff279c2a72f4ab0a37f829f7a731 MSBuildLocator.RegisterDefaults() will always register the latest version of the SDK regardless of what's pinned in global.json.

So, do we revert back to using dotnet --info again and checking the Base Path in addition to parsing SDKs from dotnet --info? Is there an argument for invoking dotnet.exe twice in order to parse Base Path from dotnet --info and then the list of SDKs from dotnet --list-sdks? The latter doesn't feel quite right.

kurtcodemander commented 3 years ago

Since it doesn't seem to be possible to get both the pinned version in use and the list of SDKs starting only one process without using dotnet --info I have made another commit going back to dotnet --info, but also making some improvements to the older version which used --info.

Now comparing each SDK path to the base path of the version in use, inserting the version in use at the top of the list whilst simply adding the rest to the list. The Reverse() have been removed since it's no longer needed.

Now, we preserve the functionality of FirstOrDefault() always returning the pinned version in use as reflected by global.json.

A separate PR should probably address the comment from @ladipro and #96

Comments on the latest commit and this way of doing it?

rainersigwald commented 3 years ago

Also, related SDK feature request: dotnet/sdk#9865. Does no good yet, of course.