Add async XLinq document/element loading and saving#2436
Add async XLinq document/element loading and saving#2436stephentoub merged 4 commits intodotnet:futurefrom
Conversation
Adds XElement.Load/SaveAsync and XDocument.Load/SaveAsync. Code from the sync versions has been largely lifted out so they can share an implementation as much as possible.
The primary set of fixes here is making the new async methods that do argument validation actually do the validation in a non-async method so that argument exceptions propagate synchronously rather than being captured into the returned tasks. In some cases, the rest of the method is pushed off into a private helper that the public method then calls; in other cases the "async" wasn't strictly necessary and can be removed to help with performance.
It wasn't overriding WriteToAsync, and as such was picking up the base XText's WriteToAsync behavior, which resulted in incorrect output for CDATA.
stephentoub
added
api-needs-work
|
@krwq, can you please review? |
|
Looks good to me! I didn't see anything obviously wrong and the tests seemed good. Thanks Steve! |
|
Thanks, Krzysztof! |
Add async XLinq document/element loading and saving
|
This is a really nice feature. Will it be part of a beta release in the near future? |
|
@stephentoub, see my question above, any idea which milestone will have this feature? |
|
I don't know. @weshaggard, can you comment? Thanks. |
|
@tmds at this point it isn't clear when this will be available in a release. We aren't in a good place yet with release packages from the open so this change would need to be adapted and brought internally by the area owner, which is @krwq in this case, because we would need to rationalize how we handle this with the full desktop framework which doesn't contain these changes, yet. |
|
@weshaggard has there been some progress? Would it be possible to set a milestone? btw, CoreCLR and full framework co-existance and release cycles seem like an interesting topic for a blog post! |
|
@weshaggard is there some progress? |
|
Sorry for the delay. Unfortunately there isn't any real progress to report on this at this time. There is also no way for you to consume these changes on .NET 4.5.1, given that these APIs ship in the box there and it does not contain them. You will only be able to consume them on a version of the full .NET framework once they are added directly there. That takes some time unfortunately. If you are interested in progress about getting these APIs merged please follow #2869, but I will warn you that it will take a while as we have other higher priority items we are currently working on. |
|
@weshaggard Thanks for the info. If I understand correctly, using it on the full desktop framework means waiting for the next release of that framework. What about the coreclr, can this (and the other features of #2869) be included in the beta builds/releases? |
|
You can of course build them yourself and run them on CoreCLR/.NET Core but we don't have all plans to push these into our official package yet. There is still a fair amount of coupling between the full framework and .NET Core that we are trying to untangle which is why we are still not building our packages externally on GitHub yet. It is a goal of mine to be able to produce our packages on GitHub by the end of the year at which time we can potentially be able to include these in the our official packages. |
|
How much further along is this one now? Any chance of an update? |
8 participants
This PR replaces #110. I rebased on future, fixed up Cory's changes (a bunch of formatting changes and renames had been merged in the meantime), and then added a few commits of my own, fixing a bug, adding some tests, etc. The tests roundtrip XML by loading and saving via both the sync and async APIs, and then compare the output, using a variety of settings.
cc: @scalablecory, @krwq, @weshaggard, @terrajobst