-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Initialize XmlReaders using StreamReaders #6863
Conversation
712b7b1
to
858187a
Compare
Digging into the error a bit more, it looks like initializing the XmlReader with a FileScheme Uri causes funky behavior when transforming an Xslt doc that calls the From what I can tell, loading the document from a stream is causing issues when calling functions from the loaded xslt. When A quick chat with Rainer showed that there's an overload to XmlReader.Create that takes a base path, and passing the original filepath ensures the path stays relative, solving the Document issue and the mangled character issue 🎉 |
To-Do: Test an xslt doc calling the |
It fails
We'd need to catch this exception and output a better string here. |
imo we merge this and file an issue in the runtime tracking this |
Issue filed: dotnet/runtime#59353 |
Following dotnet#6863, the created XmlReader is no longer responsible for its underlying stream. This can cause the build process to hold on to the processed file, preventing its removal. This can especially be a problem when the transformation is in fact aimed at the input file itself, where we want to create the transformed file, then move it to the original.
Following dotnet#6863, the created XmlReader is no longer responsible for its underlying stream. This can cause the build process to hold on to the processed file, preventing its removal. This can especially be a problem when the transformation is in fact aimed at the input file itself, where we want to create the transformed file, then move it to the original.
Following dotnet#6863, the created XmlReader is no longer responsible for its underlying stream. This can cause the build process to hold on to the processed file, preventing its removal. This can especially be a problem when the transformation is in fact aimed at the input file itself, where we want to create the transformed file, then move it to the original.
Following dotnet#6863, the created XmlReader is no longer responsible for its underlying stream. This can cause the build process to hold on to the processed file, preventing its removal. This can especially be a problem when the transformation is in fact aimed at the input file itself, where we want to create the transformed file, then move it to the original.
Following dotnet#6863, the created XmlReader is no longer responsible for its underlying stream. This can cause the build process to hold on to the processed file, preventing its removal. This can especially be a problem when the transformation is in fact aimed at the input file itself, where we want to create the transformed file, then move it to the original.
Fixes #6847
Context
When XmlReader.Create is called and a file path is passed in, it's converted to a URI under the hood. This can mangle multi-byte characters. The solution (in the link above) is to initialize the XmlReader using a stream to the file instead of the path alone.
Changes Made
Call XmlReader.Create with a stream that will detect encodings.
Testing
Tested using repro in #6847
Notes