When using XmlReader created via XmlReader.Create DTD parsing is prohibited by default (for security reasons). So it's very likely that vast majority of apps have it turned off. Trimming such app (either via PublishTrimmed=true or PublishAot=true) should ideally be able to remove all code related to DTD parsing, as it will never be used. Currently that's not the case.
Long time ago we had a similar problem where XmlReader would bring in XmlSchema and related validation classes in the default case - even though XSD validation is also off by default. This has been fixed in dotnet/corefx#23867
We should do something similar for DTD parsing. The way to fix this is to tie the dependency to DtdParser to setting the XmlReaderSettings.DtdProcessing. By default this property is Prohibit, so if it's not set, it's value will be Prohibit and thus DtdParser is not needed. If the app sets the DtdProcessing property we would have to assume that it enables it (static analysis currently can't tell the value) and make DtdParser available.
Note that the fix is not going to be as simple as it was for the XSD validation. The XmlReaderImpl has several places where it depends on DtdParser and the value of the DtdProcessing setting is copied from the settings into the reader and the reader also exposes it. So we would have to "guard" the DtdParser creation in multiple places (basically everywhere the DtdProcessing for the reader can be modified), but it definitely seems doable.
A simple experiment I did:
- Build a simple app which uses default XmlReader settings to read a simple XML file
- Trim it
- Apply a change by commenting out all uses of
DtdParser from the reader
- Trim the app again
The size difference in System.Private.Xml.dll is almost 160KB, before the change the trimmed dll is 531KB, after the change it's 373KB. That is 30% size decrease for that dll. The overall size of all managed code in the sample app is 4.2 MB.
When using
XmlReadercreated viaXmlReader.CreateDTD parsing is prohibited by default (for security reasons). So it's very likely that vast majority of apps have it turned off. Trimming such app (either viaPublishTrimmed=trueorPublishAot=true) should ideally be able to remove all code related to DTD parsing, as it will never be used. Currently that's not the case.Long time ago we had a similar problem where
XmlReaderwould bring inXmlSchemaand related validation classes in the default case - even though XSD validation is also off by default. This has been fixed in dotnet/corefx#23867We should do something similar for DTD parsing. The way to fix this is to tie the dependency to
DtdParserto setting theXmlReaderSettings.DtdProcessing. By default this property isProhibit, so if it's not set, it's value will beProhibitand thusDtdParseris not needed. If the app sets theDtdProcessingproperty we would have to assume that it enables it (static analysis currently can't tell the value) and makeDtdParseravailable.Note that the fix is not going to be as simple as it was for the XSD validation. The
XmlReaderImplhas several places where it depends onDtdParserand the value of theDtdProcessingsetting is copied from the settings into the reader and the reader also exposes it. So we would have to "guard" theDtdParsercreation in multiple places (basically everywhere the DtdProcessing for the reader can be modified), but it definitely seems doable.A simple experiment I did:
DtdParserfrom the readerThe size difference in
System.Private.Xml.dllis almost 160KB, before the change the trimmed dll is 531KB, after the change it's 373KB. That is 30% size decrease for that dll. The overall size of all managed code in the sample app is 4.2 MB.