Open vitek-karas opened 1 year ago
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.
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).
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.
Currently the root element for the various XMLs (descriptor, attributes, substitutions) is called
linker
- which is confusing. The tool is calledILLinker
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.