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
220 stars 83 forks source link

Query options and sorting #68

Closed clairernovotny closed 7 months ago

clairernovotny commented 5 years ago

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

The following would be useful:

rainersigwald commented 5 years ago

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.

https://github.com/microsoft/MSBuildLocator/blob/8b5c58f5842f58ebf860ece96ac0f6924df839b1/samples/BuilderApp/Program.cs#L26-L27

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

clairernovotny commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

rainersigwald commented 5 years ago

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 commented 5 years ago

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

rainersigwald commented 5 years ago

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 commented 1 year ago

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:

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

jnm2 commented 1 year ago

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 commented 1 year ago

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 commented 9 months ago

There's a similar problem for locating and selecting preview .NET SDKs, as logged in https://github.com/tintoy/msbuild-project-tools-vscode/issues/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 commented 7 months ago

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 commented 7 months ago

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