Open vsfeedback opened 3 years ago
Tagging subscribers to this area: @buyaa-n, @krwq See info in area-owners.md if you want to be subscribed.
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
--- ### Original Solutions (no solutions)Author: | vsfeedback |
---|---|
Assignees: | - |
Labels: | `area-System.Xml`, `untriaged` |
Milestone: | - |
@eerhardt this seems to be linker related.
Thanks for contacting us. To work around this probably for now you can disable the linker as described in https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/configure-linker?view=aspnetcore-3.1
Tagging subscribers to 'linkable-framework': @eerhardt, @vitek-karas, @LakshanF, @tannergooding, @sbomer See info in area-owners.md if you want to be subscribed.
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
--- ### Original Solutions (no solutions)Author: | vsfeedback |
---|---|
Assignees: | - |
Labels: | `area-System.Xml`, `linkable-framework`, `untriaged` |
Milestone: | - |
@joperezr is currently working on annotating System.Xml to make it linker safe.
Thanks for contacting us. To work around this probably for now you can disable the linker as described in https://docs.microsoft.com/en-us/aspnet/core/blazor/host-and-deploy/configure-linker?view=aspnetcore-3.1
I am the original poster from the dev community.
I have tried this work around and had no success. This can be tested on the sample repo at https://github.com/GilShalit/XMLValidation.
When loading a malformed XML, the message is
Xml_MessageWithErrorPosition, Xml_UnexpectedTokenEx, 6, 5
while when running locally I get
'<' is an unexpected token. The expected token is '>'. Line 6, position 5.
This is expected - to reduce the size of the app all exception messages in the framework are removed. If you need to enable them, set UseSystemResourceKeys
property to false and rebuild.
This is expected - to reduce the size of the app all exception messages in the framework are removed. If you need to enable them, set
UseSystemResourceKeys
property to false and rebuild.
Yes! This works! So will use this as a work around until @joperezr makes System.Xml linker safe...
But this raises a question - how can XML validation be performed if all exception messages are removed? Is this temporary?
I just want to point out that the removal of exception messages will remain - even once the assembly is trim compatible. it actually saves quite a bit of size for Blazor.
I just want to point out that the removal of exception messages will remain - even once the assembly is trim compatible. it actually saves quite a bit of size for Blazor.
Sorry, edited my response while you were pointing out... So will we not be able to perform XML validation without setting UseSystemResourceKeys to true?
The validation will work in that you will get the same exceptions at the same time - it's just the exception messages which will be different. If you need the existing exception messages then using the UseSystemResourceKeys=false
is the way to go - but be aware of the size penalty for it. Currently we don't have a way to set this per-assembly, so it will apply to the entire framework.
Finally read the actual issue posted above - the planned work to make System.Xml trim compatible will have no effect on this issue.
the planned work to make System.Xml trim compatible will have no effect on this issue.
Sorry 😊 that was me reading the issue too fast and not fully grasping the issue.
The validation will work in that you will get the same exceptions at the same time - it's just the exception messages which will be different. If you need the existing exception messages then using the
UseSystemResourceKeys=false
is the way to go - but be aware of the size penalty for it. Currently we don't have a way to set this per-assembly, so it will apply to the entire framework.
I wander if having a per assembly setting does not make sense in a future version. There are business processes that depend on event processing and stripping out the event messages is crippling. XML validation is a case in point - the Microsoft documentation calls for creating a ValidationEventHandler
and processing it's messages. The promise of Blazor as allowing the power of .Net in the browser is not fulfilled here...
Maybe a better solution would be to have a set of specific features which allow per-feature inclusion of exception messages. For example the XML schema validation lives in the same assembly as pretty much everything else from XML, and you're probably not interested in exception messages for XmlWriter and so on.
I'm just curious - what is the scenario of XML schema validation on the Blazor client side? (Also please note that the perf is probably going to be another issue with such setup - processing even medium size XMLs this way will probably be VERY slow in the browser. We're working on it, but right now from what I've tried, it's pretty slow).
Your solution makes a lot of sense.
The scenario is creating a Tei XML editor for preparing annotated Tei editions in Digital Humanities research projects. Validating a 300kb XML file takes a second or two which is acceptable.
I'm using Blazor WebAssembly because I want to create a browser-only solution to be served as static files to reduce costs to a minimum. And because I wanted to learn this new framework after not enjoying Angular/React at all...
Thanks a lot for the scenario description. Makes sense.
@GilShalit as explained above unfortunately today the only way to workaround this is by setting that property to false and rebuilding. The exception messages that you will get aren't really "meaningless", and technically you could still map the key with the actual message that would have been printed, for example: Your particular message is created in this line:
which maps to
And Xml_UnexpectedTokenEx maps to
All that said, is it ok from your side to set the property to false as a solution taking into account that this will cause an increase size in your application? (Given that by setting that to false, now all framework string resources from the framework like exception messages will not be trimmed from your application) In case the answer to that question is no, then we can have a feature request to have a control knob when trimming resources based on specific feature areas like @vitek-karas suggests.
@joperezr I am currently setting the property to false in my shipping tool and living with the increased application size. But I think of it as a sub-optimal solution and I think a (not extremely urgent) feature request should be added for the control knob to trim resources selectively as per @vitek-karas 's suggestion.
Another point is that I was floored by the different behavior in development and running on the localhost, where nothing was trimmed to the behavior in production. Not sure what the solution should be but I thing this should either be changed or better highlighted somewhere.
This issue has been moved from a ticket on Developer Community.
[severity:I'm unable to use this version] The following code works fine on localhost, but produces limited error messages when deployed to an Azure Static Web App through GitHub.
When loading the badly formed XML file books.html (attached), the line
document. Load(xmlReader);
fires an error. The problem is that while on localhost this error has a meaningful message, such as:The deployed version produces a meaningless error message:
Am I doing something wrong? Is this a bug?
I have created a public repo at https://github.com/GilShalit/XMLValidation
[Books.xml] (https://aka.ms/dc/file?name=B46c6ab30f4824fb888ce490ae7655355637503790903832654_Books.xml&tid=46c6ab30f4824fb888ce490ae7655355637503790903832654)
Original Comments
Feedback Bot on 3/3/2021, 11:00 PM:
We have directed your feedback to the appropriate engineering team for further evaluation. The team will review the feedback and notify you about the next steps.
Original Solutions
(no solutions)