Query options and sorting

[clairernovotny]

As far as I've seen, there's no way to sort or filter on VS options.

The following would be useful:

• Specify 2019 or 2017
• Preview or Stable
• Sort (ascending/descending, can be combined with preview/stable)

[rainersigwald]

The philosophy so far has been to push this onto the calling code, allowing it to get a list of options and filter/sort that in its own way.

MSBuildLocator/samples/BuilderApp/Program.cs

Lines 26 to 27 in 8b5c58f

	var instances = MSBuildLocator.QueryVisualStudioInstances().ToList();
	var msbuildDeploymentToUse = AskWhichMSBuildToUse(instances);

Do you think there's a better API that we could provide? What would that look like?

[clairernovotny]

The problem with "Ask what to use" is that it may not be interactive.

From an API perspective, I think filters could be added to the query option. It would make it declarative, "give me 2019 or return emtpy if not found"

[clairernovotny]

Another idea, which could be combined with the query option, is to add additional properties to the instance objects, for the version number and channel name.

I realize that Version exists, but it's not clear if it's 16.0, 16.1, 16.1.2, etc. A family enum like 2019 may help. I didn't see "IsPrerelease" for a channel or a channel name.

[rainersigwald]

I'd be on board with adding fields to our object to make filtering easier. Unfortunately, the things you're interested in don't seem to be available in ISetupInstance2.

Adding filtering options to the query doesn't strike me as better than letting the caller do it, though.

[clairernovotny]

Does one of those at least indicate the channel name & stable/pre-release-ness? That'd be a good starting point.

[rainersigwald]

Not that I can see. The only "properties" I see are:

campaignId: 1060713956.1557239266
setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe
nickname:
channelManifestId: VisualStudio.16.Release/16.1.1+28922.388

[clairernovotny]

How does vswhere do it then, there must be a way? It has a -prerelease flag (and skips those by default).

[rainersigwald]

Happened to be looking at something nearby today, and noticed that the sample VS Setup API application emits some information that looks related to these things.

Evidently IsPrerelease is available under ISetupInstanceCatalog

https://github.com/microsoft/vs-setup-samples/blob/8fcafdb17bd1df6ac7a59a22ce362e999bc33a5a/Setup.Configuration.CS/Program.cs#L75-L79

and one of these catalog properties is probably channel-like:

InstanceId: 4e0a5c96 (Complete)
InstallationVersion: 16.2.29201.188 (4503610131022012)
InstallationPath: C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise
IsPrerelease: False
Product: Microsoft.VisualStudio.Product.Enterprise
Workloads:
    Microsoft.VisualStudio.Workload.CoreEditor
    Microsoft.VisualStudio.Workload.ManagedDesktop
    Microsoft.VisualStudio.Workload.NativeDesktop
    Microsoft.VisualStudio.Workload.NetCoreTools
    Microsoft.VisualStudio.Workload.NetWeb
    Microsoft.VisualStudio.Workload.Universal
    Microsoft.VisualStudio.Workload.VisualStudioExtension
Custom properties:
    campaignId: 1060713956.1557239266
    channelManifestId: VisualStudio.16.Release/16.2.1+29201.188
    nickname:
    setupEngineFilePath: C:\Program Files (x86)\Microsoft Visual Studio\Installer\vs_installershell.exe
Catalog properties:
    buildBranch: d16.2
    buildVersion: 16.2.29201.188
    id: VisualStudio/16.2.1+29201.188
    localBuild: build-lab
    manifestName: VisualStudio
    manifestType: installer
    productDisplayVersion: 16.2.1
    productLine: Dev16
    productLineVersion: 2019
    productMilestone: RTW
    productMilestoneIsPreRelease: False
    productName: Visual Studio
    productPatchVersion: 1
    productPreReleaseMilestoneSuffix: 1.0
    productSemanticVersion: 16.2.1+29201.188
    requiredEngineVersion: 2.2.3062.31357

Eyeballing against my internal-preview install, I think manifestName might be the one to look at. Would need to compare on a machine that has a public preview installed.

I'm trying to decide if we should expose certain fields directly, or just return the whole ISetupInstance2 and let the caller do arbitrary filtering. Or some combination: we do prerel and channel and also expose the full interface?

[jnm2]

The ability to filter to require workloads/components is important, too. Finding the wrong VS Build Tools installation was the cause of the The SDK 'Microsoft.NET.Sdk' specified could not be found failure for us, and I see a couple issues in this repo with that same message.

On a build server with:

• VS Build Tools 2019 with no workloads and only certain components installed
• VS Build Tools 2022 with .NET web and desktop workloads

RegisterDefaults() will pick 2019 and not be able to work with Microsoft.CodeAnalysis.Workspaces.MSBuild.

[jnm2]

Would you accept a PR to expose the information in ISetupInstance2.GetPackages() through VisualStudioInstance and let folks do their own filtering?

Optionally, new APIs roughly like this could be added to make this (hopefully common) usage easier:

MSBuildLocator.RegisterLatest(new VisualStudioInstanceQueryOptions
{
    RequiredComponents = { RequiredComponent.DotNetSdk },
});

[rainersigwald]

Would you accept a PR to expose the information in ISetupInstance2.GetPackages() through VisualStudioInstance and let folks do their own filtering?

Yes.

Optionally, new APIs roughly like this could be added to make this (hopefully common) usage easier:

MSBuildLocator.RegisterLatest(new VisualStudioInstanceQueryOptions
{
    RequiredComponents = { RequiredComponent.DotNetSdk },
});

That is slick--but where are the components defined? I'd rather not have to replicate lists from VS Setup if we can delegate to it.

[baronfel]

There's a similar problem for locating and selecting preview .NET SDKs, as logged in tintoy/msbuild-project-tools-vscode#144.

The current logic asks the hostfxr to list SDKs, but the hostfxr call doesn't seem to support listing previews through the APIs. I haven't checked yet to see if the rollforward selection environment variables can influence this call, though. There's a separate hostfxr call that can do selection of the correct SDK including previews, but that doesn't seem to be a 1;1 match with the call we're using now, so we may need the runtime to fill this gap.

[YuliiaKovalova]

Hi @clairernovotny,

The ability to query preview versions was added in the recent package:
https://www.nuget.org/packages/Microsoft.Build.Locator/1.7.8

Please let us know if it partially resolves your request.

[YuliiaKovalova]

Feel free to reopen and specify what else is missing for your current needs.