New releases of XmlResolver for C#
Published by Recently, I’ve made a few fixes to the C# version of the XML Resolver. If you’re using it, I humbly suggest you might want to consider upgrading.
TL;DR. If you’re using XmlResolver on .NET, get the 2.1.0 release of XmlResolver and the 1.2.3 release of XmlResolverData.
I was sure that I’d made a blog post, either here or on Saxon Chronicles, about the 1.0 release of XmlResolver on the .NET platform. But apparently not.
That was just a little over a year ago and I’ve pushed a number of bug fixes and improvements since then. About a week ago, I pushed a 2.0.0 release.
The big change in 2.0.0 is that my code for finding catalogs and catalog data in other assemblies (including the assembly in the companion package XmlResolverData) was just wrong. I was looking for the other assemblies not by name but by location. That’s not recommended and just plain doesn’t work if you’ve compiled your code into a single executable.
I decided that change was backwards incompatible and warranted a 2.x release, but in practice I don’t expect it’ll have negative consequences. There’s no evidence anyone but me was using that feature and if you were finding your assembly by location, you should be able to find it by name. And finding by name will work even if you package it up as a single executable. But it’s still an incompatible API change, so 2.x.
Other fixes in the 2.x branch include support for .NET 6 (instead of
.NET 5) and replacing the deprecated WebClient class with
HttpClient. That also introduced a small API change.
Just today, I pushed 2.1.0 to fix a bug I managed to trip over:
in the resolver, there’s a utility class for loading a Stream from a
Uri. I had carelessly implemented that in a way that obscured HTTP
response codes. You’d get back an apparently successful stream
response even if the server returned 404.
That’s…uh…misleading.
The API has no facility for returning a StatusCode so I’ve taken the
draconian stance that only an OK (200) response constitutes success.
The HttpClient resolves redirects, so a 302 to a 200 will succeed.
But a 404 will fail. Anything except 200 will fail.
It’s a utility class. If that’s not what you want, don’t use it.
Earlier this week, I fixed a bug in XmlResolverData too. The code for generating the catalog was missing out namespace URIs. (So you couldn’t, for example, find an XML schema by it’s target namespace, you could only find it by one of its location hints.) That bug was not present in the Java version of the data jar, so there’s no corresponding update there.
(Ignore the fact that the 1.2.0 release doesn’t exist and the fact that the release tagged 1.2.2 claims to be 1.2.1, ok? I had some issues with workflows. ☺)