[3rd party] Meadow - track compatible projects in workspace

[Redth]

Is your feature request related to a problem? Please describe.

Similar to #5805 and #5806 today the Meadow extension for VSCode relies on O# events to be notified when the projects in the workspace change. It uses this event to then parse the project workspace in order to determine if there are Meadow compatible projects in the workspace to enable Meadow specific UI and functionality.

Describe the solution you would like

Ideally Meadow could subscribe to a specific query where it matched projects with a known ProjectCapability, and could return matching projects and ideally infer a few evaluated msbuild property values for things like the project output path and build configuration.

Applicable Scenarios

Meadow IoT developers using the VSCode Meadow Extension

Describe alternatives you've considered

Meadow could watch the workspace for .csproj files and parse them out, or even create a shadow Roslyn MSBuild instance to track changes and evaluate properties, however this seems prone to interfering with csdevkit's project system.

[dibarbet]

FYI @jasonmalinowski for project info requests.

[jasonmalinowski]

@Redth: you roughly described what you're doing but just so we have a bit more info, which properties do you need to look at? And what project capability are you filtering to?

[Redth]

@jasonmalinowski in the case of Meadow, there's currently a Meadow ProjectCapability that would probably be used.

As far as properties, this may not be an exhaustive list of what would be useful but a good start:

• MSBuildProjectFullPath
• OutputPath
• OutputType
• Configuration
• OS
• TargetPath
• TargetFileName
• TargetFramework

From the binlog I was referencing, these properties all look like they have the values needed right after the initial project evaluation.

[jasonmalinowski]

@Redth OK, that's a pretty common list. What do you do with Configuration and TargetFramework? And I should have asked earlier, is the code here open source so we can just take a peek?

[Redth]

Stepping back a bit again, I believe the main requirements here are:

• Knowledge of 'Meadow' compatible projects in the workspace (eg: to activate/deactivate relevant UI, commands, debug)
• Evaluated values of msbuild properties of those projects (eg: to be able to find the TargetFileName for post build steps such as custom deployment and packaging)
• ProjectCapabilities of those projects to be able to filter for "Meadow" or to have the knowledge of projects in the workspace already filtered to this.

Configuration would be used to support dynamic build task definitions for things like debugging. A custom meadow debug config provider might execute a prelaunch task that executes dotnet build with some specific parameters for debugging and target device).

TargetFramework might not be expressly needed but I could see it being useful for pivoting some custom post build or debugger logic.

Arguably it might be ok to not have the msbuild evaluated properties, though it would make things easier short term. Eventually Meadow could plausibly do any custom post build packaging/deploy/debug tasks closer to MSBuild as an actual msbuild task and participate in dotnet run/dotnet publish for example. Today that's not how it works though, so having some of these values is very useful.

[Redth]

Expanding on the msbuild properties, worst case some custom targets could be injected into a dynamic build task definition in vscode which would produce a temp file with the values.

So if there's any help in prioritizing asks here, definitely knowledge of Meadow capable projects within the workspace and notifications of that set of projects changing is by far the biggest ask. The msbuild property values there are plausible workarounds for even today.