Update XSD for new SDK-style CSPROJ properties

[DamianEdwards]

There have been many new properties (and maybe even some items) added to the .NET base, Razor, and Web SDKs which don't seem to be present in the XSD, meaning folks in Visual Studio editing the CSPROJ file directly don't see statement completion for them. Let's use this issue to list them and get them added.

Property Name	Possible Values	Description/Documentation	Source SDK/Targets
TieredCompilation	true,false	Indicates whether the runtime should enable tiered JIT compilation.	Microsoft.NET.Sdk (TBC)
ServerGarbageCollection	true,false	Indicates whether the runtime should enable the server garbage collection mode.	Microsoft.NET.Sdk (TBC)
UserSecretsId	any string	The ID that will be used to locate the file storing secret configuration values for this project at development time.	Microsoft.NET.Sdk.Web (TBC)

@livarcocc @davidfowl

[dasMulli]

It seems that there should be some new way for VS to "discover" properties and maybe even items+metadata. Maybe even "public target names" (= things to put in BeforeTargets/AfterTargets).

Right now, the XSD properties will be available to every project, no matter which SDK is used, even in classic projects.

Ideally, this could be a property/item added by the SDKs, maybe even NuGet targets, linking to some kind of specification file for props/items/targets that the editor would then light up for that project file.

The classic project system supported AvailableItemName items to extend the property window UI (dotnet/project-system#113 for new project system), but having some way to extend the IntelliSense for the project would be even greater. Preferably in a way that doesn't add too much evaluation time (e.g. linking a few spec xml files, not adding hundreds of items in imported files - unless this isn't much of a difference)

[natemcmaster]

Is there a list somewhere of which properties are already known about? There are dozens we could add to this list.

[rainersigwald]

@natemcmaster IntelliSense in VS is driven by the XSD files checked into this repo, primarily https://github.com/Microsoft/msbuild/blob/master/src/MSBuild/Microsoft.Build.CommonTypes.xsd

In addition, properties are documented in various places on MSDN; the main one is https://docs.microsoft.com/en-us/visualstudio/msbuild/common-msbuild-project-properties but each SDK can define its own properties and often they get documented at the SDK level.

Adding things to the XSD makes them available everywhere, which is kinda unfortunate, since not every property applies to every project. But it's what we've got at the moment (in lieu of #1774 or something like it), so no real harm in expanding it.

[NTaylorMullen]

Razor relevant properties:

Property Name	Possible Values	Description/Documentation	Source SDK/Targets
RazorCompileOnBuild	true, false	Indicates whether Razor files should be compiled at build time.	Microsoft.NET.Sdk.Razor
RazorCompileOnPublish	true, false	Indicates whether Razor files should be compiled at publish time.	Microsoft.NET.Sdk.Razor
UseRazorBuildServer	true, false	Indicates whether Razor code generation should use a persistent build server process.	Microsoft.NET.Sdk.Razor
RazorOutputPath	directory path	Directory for Razor output.	Microsoft.NET.Sdk.Razor
EnableDefaultRazorGenerateItems	true, false	Set to true to automatically include Razor (.cshtml) files in @(RazorGenerate) from @(Content).	Microsoft.NET.Sdk.Razor
EnableDefaultContentItems	true, false	Set to true to automatically include certain file types, such as .cshtml files, as content in the project. When referenced via Microsoft.NET.Sdk.Web, this additionally includes all files under wwwroot, and any config files.	Microsoft.NET.Sdk.Web and Microsoft.NET.Sdk.Razor
EnableDefaultRazorComponentItems	true, false	Set to true to automatically include Razor (.razor) files in @(RazorComponent) from @(Content).	Microsoft.NET.Sdk.Razor
CopyRazorGenerateFilesToPublishDirectory	true, false	Set to true to copy RazorGenerate items (.cshtml) to the publish directory. Typically Razor files are not needed for a published application if they participate in compilation at build-time or publish-time. By default, the Razor SDK will suppress the copying of RazorGenerate items to the publish directory.	Microsoft.NET.Sdk.Razor
CopyRefAssembliesToPublishDirectory	true, false	Set to true to copy reference assembly items to the publish directory. Typically reference assemblies are not needed for a published application if Razor compilation occurs at build-time or publish-time. By default, the Razor SDK will suppress the copying of reference assemblies to the publish directory.	Microsoft.NET.Sdk.Razor
IncludeRazorContentInPack	true, false	Configures whether all Razor content items (.cshtml files) will be marked to be included in the produced NuGet package as content. All Content items are included in a NuGet package as content files. This setting can be used to control this behavior for Razor content items.	Microsoft.NET.Sdk.Razor
PreserveCompilationContext	true, false	Set to true to allow Razor compilation to compile the projects Razor files in the context of the applications dependencies.	Microsoft.NET.Sdk.Razor
RazorTargetName	any string	File name (without extension) of the assembly produced by Razor	Microsoft.NET.Sdk.Razor
EmbedRazorGenerateSources	true, false	Configures whether all of the @(RazorGenerate) items will be added as embedded files to the produced assembly. When true, everything in @(RazorGenerate) will be added to @(RazorEmbeddedFiles) and passed to CSC.	Microsoft.NET.Sdk.Razor

[JunTaoLuo]

gRPC relevant properties:

Property Name	Possible Values	Description/Documentation	Source SDK/Targets
DisableProtobufDesignTimeBuild	true, false	Indicates whether Design Time Build should be disabled for referenced @(Protobuf) files.	Grpc.Tools

[DamianEdwards]

Some properties from NuGet and .NET Core 3.0 SDK:

Property Name	Possible Values	Description/Documentation	Source SDK/Targets
RestoreSources	semi-colon delimited list of NuGet package feed URIs	The feeds that NuGet will use for restoring packages for this project.	NuGet
PackageLicenseExpression	An SPDX identifier for the package's license (see https://docs.microsoft.com/en-us/dotnet/standard/library-guidance/nuget#important-nuget-package-metadata)	The project license's SPDX identifier. Only OSI and FSF approved licenses can use an identifier. Other licenses should use PackageLicenseFile. Read more about license metadata.	NuGet
PackageLicenseFile	file path	A path to the package's license file. Should only be used when the package doesn't use an OSI or FSF approved license.	NuGet
PackageType	Semi-colon delimited list of type enums and versions, see https://docs.microsoft.com/en-us/nuget/reference/msbuild-targets	Indicates what the intended package use is, e.g. .NET CLI global tool, standard dependency, etc.	NuGet
PublishReadyToRun	true or false	Indicates whether the project should produce ReadyToRun images during publish.	.NET SDK 3.0
PublishSingleFile	true or false	Indicates whether the project should produce a self-extracting executable during publish.	.NET SDK 3.0
PublishTrimmed	true or false	Indicates whether the project should produce trimmed assembly images during publish.	.NET SDK 3.0

Also, the following meta-data attributes for <PackageReference /> should be added (they currently only show up as child nodes, but they're valid and often used as attributes directly):

• IncludeAssets
• ExcludeAssets
• PrivateAssets

The IL Linker support in .NET SDK 3.0 adds some new item types that are defined at
https://github.com/mono/linker/blob/master/src/ILLink.Tasks/README.md:

• TrimmerRootAssembly
• TrimmerRootDescriptor

.NET SDK 3.0 also adds the new FrameworkReference item type, for defining references to targeting packs.

[NTaylorMullen]

@pranavkm you should add some of the more recent Razor properties here (in addition to what I have above)

[DamianEdwards]

Found another new meta-data element/attribute to add: ExcludeFromSingleFile

It's used to exclude items (e.g. Content) from being included in the generated single file executable when PublishSingleFile is being used.

[dasMulli]

While I appreciate more useful stuff being added to the XSD for completion, I fear that this will quickly become unmanageable over the next years.. And the more stuff is added, it may not make sense out of context (Intellisense for RazorCompileOnBuild for a console app not using razor?) and clutter the completion list (given that A LOT of things now start with Enable or Disable).
So I believe that a good project system should be a high priority for improving the tooling experience, esp. one that could be reused across VSCode/VSmac/VS/Rider/**.