Support different name for the XML root element

[vitek-karas]

Currently the root element for the various XMLs (descriptor, attributes, substitutions) is called linker - which is confusing. The tool is called ILLinker and the verb we use to describe the process is "trimming". We're trying to avoid "linking" everywhere to not create confusion with platform linker.

We can't remove support for the linker element, too much backward compat, but we can easily teach the tool to accept a different name as well, and change our docs to refer to the new name.

Ideas: trim, trimming, trimmer

Suggestions welcome.

[MichalStrehovsky]

We could go with something more descriptive, such as using descriptor for the descriptor format. AFAIK we don't document the substitution or attribute format on docs.microsoft.com and those are therefore unsupported.

But it feels like it's just putting lipstick on a pig: having a sidecar XML is a terrible experience to begin with, and then one gets hit by type name syntax that doesn't match anything .NET developers are used to seeing (because the syntax is "whatever Cecil accepts"), etc.

A good fix for this might be to just declare these file formats are for backwards compatibility only and place any references to them in docs.microsoft.com to a section that only shows up if you want docs for an old version of .NET. Point everyone to DynamicDependency for later .NET and use that to identify any other gaps we need to address.

[marek-safar]

We cannot declare these file formats for backward compatibility as we have no replacement for many features used there. DynamicDependency covers only a narrow scenario with limits. My preference would be to change it to trimming because XML information is used only when trimming is enabled and that runs as part of 4 or so tools already (none of them is called trimmer).

[MichalStrehovsky]

as we have no replacement for many features used there

Yep, that's what I meant with "Point everyone to DynamicDependency for later .NET and use that to identify any other gaps we need to address.".

The XMLs pre-date a lot of the other trimming work we did (dataflow, DynamicDependency). We would not pull the support, just stop advertising it and see if there's scenarios we don't cover. Maybe we don't need to be able to replicate every single things expressible with the XMLs because there wouldn't be a need for it in the new world. XML is a bad user experience (and bad for trimming because it's not attached to the code that uses it) - users shouldn't take that route if there's a different way.