Return SDKs from all dotnet location by JoeRobich · Pull Request #329 · microsoft/MSBuildLocator

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Joey Robichaud (JoeRobich) · 2025-03-19T23:02:41Z

Review with whitespace off as the formatter removed trailing whitespace.

The method which finds all SDKs has an early exit which stops it from finding SDKs from more than one dotnet install. This PR removes the early exit and filters the returned instances by their reported version number. This should deduplicate the SDKs.

Joey Robichaud (JoeRobich) · 2025-03-20T00:01:52Z

+ {
+ string? bestSdkPath;
+ string[] allAvailableSdks;
+ try


Inlined GetDotNetBasePaths

Joey Robichaud (JoeRobich) · 2025-03-20T00:03:02Z

- string? bestSDK = GetSdkFromGlobalSettings(workingDirectory);
- if (!string.IsNullOrEmpty(bestSDK))
+ // Returns the list of all available SDKs ordered by ascending version.
+ static string[] GetAllAvailableSDKs()


This method and GetSdkFromGlobalSettings were only referenced from the inlined GetDotNetBasePaths so I made them local functions.

Joey Robichaud (JoeRobich) · 2025-03-20T00:12:03Z

- for (int i = dotnetPaths.Length - 1; i >= 0; i--)
- {
- if (dotnetPaths[i] != bestSDK)
+ if (rc == 0 && resolvedPaths != null)


Previous behavior was that we would not throw if resolvedPaths was an empty array.

Forgind

I think this would work the way I'd expect! Chet Husk (@baronfel) mentioned a concern about diverging from dotnet.exe's behavior in not using other dotnet.exes, but I would want to better understand his reasoning, as I'd argue that MSBuildLocator is (and always has been) more flexible with respect to which MSBuild it ultimately loads than dotnet.exe is, so I see no reason it shouldn't also be more flexible as far as which it finds. That said, we should still solicit feedback from MSBuild, as I don't actually own this product 🙂

YuliiaKovalova · 2025-03-28T09:04:01Z

it looks good to me, Rainer Sigwald (@rainersigwald) do you have any concerns?

Rainer Sigwald (rainersigwald) · 2025-03-28T14:43:10Z

+ // We want to return the newest SDKs first. Using OfType will remove the null entry added if we found the best SDK.
+ var instances = versionInstanceMap.Values.OfType<VisualStudioInstance>().OrderByDescending(i => i.Version);


I am finding this sort confusing with respect to your comment above about keeping the precedence order. That is just per-version, but you'd prefer the overall results sorted by version?
Can you go into more detail on your use case?

I was trying to preserve the behavior from this comment:
// We want to return the newest SDKs first, however, so iterate over the list in reverse order.
But you are right. I cannot guarantee this will maintain the precedence ordering.
We intend to use this from the MSBuildWorkspace buildhost where we are looking for an SDK and we don't really care where it comes from. If they have pinned a version then we would like to find it, otherwise we would take the SDK with the highest version from any install location.

Yeah that makes sense I think. The question I have is whether we should embed the sort here, or push it to the caller's layer. I don't think I have super strong opinions so this is fine.

Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Rainer Sigwald (rainersigwald)

I guess this should be a minor version bump, for adding the feature to request this?

Joey Robichaud (JoeRobich) · 2025-03-28T22:29:44Z

I guess this should be a minor version bump, for adding the feature to request this?

Want me to do that in this PR? or as a follow up?

DERP (darikprescott)

Seems very logical to provide a mechanism to allow faster delivery of sdks and being able to find them faster.

YuliiaKovalova · 2025-03-31T10:01:51Z

I guess this should be a minor version bump, for adding the feature to request this?
Want me to do that in this PR? or as a follow up?

I have bumped the version , no worries!
Thank you for the contribution.

Rainer Sigwald (rainersigwald) · 2025-03-31T14:09:02Z

DERP (@darikprescott) Note that being able to locate the new SDKs does not do anything to make them more loadable; if you wanted to take advantage of this you'd need a big bag of tricks to find and load a newer runtime to load the newer SDK.

YuliiaKovalova · 2025-03-31T15:56:06Z

It has been released:https://www.nuget.org/packages/Microsoft.Build.Locator/1.8.1 :)

Return SDKs from all dotnet location
de9afce

Forgind reviewed Mar 19, 2025
View reviewed changes

Comment threadsrc/MSBuildLocator/DotNetSdkLocationHelper.cs Outdated

Preserve ordering of returned SDKs across dotnet instances.
6314d67

Joey Robichaud (JoeRobich) commented Mar 20, 2025
View reviewed changes

Yield return all the available SDKs
2424986

Joey Robichaud (JoeRobich) commented Mar 20, 2025
View reviewed changes

Forgind approved these changes Mar 20, 2025
View reviewed changes

Comment threadsrc/MSBuildLocator/DotNetSdkLocationHelper.cs Outdated

Add query option to search all dotnet locations
302e031

Joey Robichaud (JoeRobich) marked this pull request as ready for review March 25, 2025 20:24

Rainer Sigwald (rainersigwald) reviewed Mar 28, 2025
View reviewed changes

Joey Robichaud (JoeRobich)and others added 2 commits March 28, 2025 13:38

Fix up comment wording
52a422e
Co-authored-by: Rainer Sigwald <raines@microsoft.com>

Use TryAdd
298418b

Rainer Sigwald (rainersigwald) approved these changes Mar 28, 2025
View reviewed changes

DERP (darikprescott) approved these changes Mar 29, 2025
View reviewed changes

bump the version to 1.8
4a8eac4

YuliiaKovalova enabled auto-merge (squash) March 31, 2025 10:03

YuliiaKovalova merged commit 6235ee4 into microsoft:mainMar 31, 2025

dependabotBot mentioned this pull request Jul 28, 2025
Bump ICSharpCode.Decompiler and 5 others waf/CSharpRepl#406
Closed

dependabotBot mentioned this pull request Aug 18, 2025
Bump the dotnet-dependencies group with 25 updates jasonlittleton316/CSharp-Repl-test#23
Closed

This was referenced Apr 22, 2026
Bump the dotnet group with 8 updates irgiys/DotNet.GitHubAction#9
Closed
[deps]: Bump Microsoft.Bcl.AsyncInterfaces and 6 others netinlet/Parlance#118
Closed
[deps]: Bump Microsoft.Bcl.AsyncInterfaces and 6 others netinlet/Parlance#121
Closed

This was referenced May 4, 2026
[deps]: Bump Microsoft.Bcl.AsyncInterfaces and 6 others netinlet/Parlance#119
Closed
[deps]: Bump the minor-and-patch group with 9 updates netinlet/Parlance#122
Closed
Bump the dotnet group with 9 updates irgiys/DotNet.GitHubAction#12
Closed

This was referenced May 11, 2026
[deps]: Bump Microsoft.Bcl.AsyncInterfaces and 7 others netinlet/Parlance#123
Closed
Bump the dotnet group with 9 updates irgiys/DotNet.GitHubAction#13
Closed

This was referenced Jun 10, 2026
Bump the dotnet group with 9 updates irgiys/DotNet.GitHubAction#14
Open
[deps]: Bump coverlet.collector and 8 others netinlet/Parlance#140
Closed
Bump the dotnet-sidecars group with 3 updates Nimblesite/SharpLsp#98
Closed

This was referenced Jul 2, 2026
Bump Microsoft.Build.Locator and 7 others bigdra50/unilyze#230
Merged
Bump Microsoft.Build.Locator from 1.2.2 to 1.11.2 jackytea/sandbox-world#1
Closed

dependabotBot mentioned this pull request Jul 15, 2026
[release/9.0]: Bump Microsoft.Build.Locator from 1.7.8 to 1.11.2 dotnet/efcore#38636
Closed

dependabotBot mentioned this pull request Aug 12, 2026
Bump BenchmarkDotNet and 9 others leonardochaia/dotnet-affected#173
Closed

This was referenced Aug 19, 2026
Bump BenchmarkDotNet and 10 others leonardochaia/dotnet-affected#185
Closed
Bump the dotnet group with 11 updates leonardochaia/dotnet-affected#188
Closed