Support packages/custom Sdks to provide their own XSD

[Youssef1313]

Summary

Today, csproj IntelliSense is only driven by XSDs provided by MSBuild. I think it would be nice to have some sort of extensibility and allow NuGet packages and/or custom MSBuild Sdks to provide their own XSD.

Background and Motivation

Many NuGet packages (regular ones and Sdks) offer some MSBuild properties intended for use by consumers. Today, first-party authors have to make the change in this repo, and third-party authors have no way to do it (assuming they don't go too crazy and grab the XSD from VS installation and attempt to modify it).

Proposed Feature

Not sure if the exact shape or technical limitations here, but having something like Sdk.xsd (like Sdk.props and Sdk.targets that are special cased for custom Sdks) would be nice. For regular NuGet packages, it could be build\<PackageName>.xsd.

Any other design that solves the problem is also good.

Alternative Designs

No response

[Evangelink]

cc @YuliiaKovalova @JanKrivanek @rainersigwald

[KalleOlaviNiemitalo]

Ideas:

• An MSBuild file in the NuGet package adds items to a new item type, e.g. MSBuildXmlSchema. Visual Studio (or dotnet/project-system?) evaluates the project, reads these items, and configures the XML editor. Would be controlled as part of build or buildTransitive in IncludeAssets and ExcludeAssets.
  • pro: Would work in MSBuild project SDKs too, with no extra effort.
  • con: Could slow down MSBuild evaluation a bit; but the effect would depend on how many packages provide XML schemata, and most packages probably won't.
• A new NuGet asset type. NuGet restore lists the schema files in project.assets.json and VS reads from there.
  • pro: More control.
  • con: Needs changing NuGet too.
  • con: MSBuild project SDKs cannot declare schema files because they are not listed in project.assets.json.
• VS locates schema files from a hardcoded path within packages listed in project.assets.json.
  • pro: VS-only change.
  • con: App developer cannot declare whether the schemata should be used.
  • con: MSBuild project SDKs cannot declare schema files because they are not listed in project.assets.json.

General problem: PackageReference conditional on TargetFramework. If the project is multitargeted and different target frameworks use different versions of the same package, then which version of the XML schema should be used by the XML editor?

General problem: if the VS user opens a file that is imported to multiple projects that reference packages that carry MSBuild XML schema files, how does VS choose the project whose package references should control the schemata in the XML editor?

[Youssef1313]

General problem: if the VS user opens a file that is imported to multiple projects that reference packages that carry MSBuild XML schema files, how does VS choose the project whose package references should control the schemata in the XML editor?

Good question. I think that should be a merge of everything. In case of conflicts, it could show the property multiple times. For example, MyProperty (package ... version ...), then the tooltip for each of these can have the description from the specific package.