home: Xml Deserialization Error

I am getting this error when deserializing an XML string with version 2.1.2:

An attempt was made to load a type with the fully qualified name of ‘http://namespace/file.xsd:myMessage’, but no type could be located with that name.

XML:

<?xml version="1.0"?>
<myMessage xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="http://namespace/file.xsd">
  <myElement uniqueId="12345"> 
</myMessage>

Class:

// <remarks />
[Serializable]
[XmlType(AnonymousType = true, Namespace = "http://namespace/file.xsd")]
[XmlRoot("myMessage", Namespace = "http://namespace/file.xsd",
    IsNullable = false)]
public class MyMessage
{
    /// <remarks />
    [XmlElement("myElement")]
    public MyElementType MyElement { get; set; }
}

Call to the serializer:

_xmlSerializer.Deserialize<MyMessage>(xml)

Possibly related to #99

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Comments: 24 (16 by maintainers)

Commits related to this issue

Most upvoted comments

For sure @wojtpl2 … looks like d4d99cc633217f473a9e32e0fb7042892f6369f3 is the winner here. 👍

I’ve just published version 2.1.2.

Actually you did provide the test earlier, I just didn’t use it. 👼 … but the problem here is identity resolution, obviously. It might help to make use of the Serialize method to see how it is emitted, first. CLR types are emitted with a Xaml-esque namespace attribute unless their assembly is registered as a root identity (e.g sys or exs). So we do a good job (now) of accounting for names, but namespaces are not registered (nor checked). The good news is that it’s mostly in place to do so and I should have something shortly here for you to test. Again. 😆

Boh! Yeah that’s a minor detail isn’t it. 😛 … We’re still emitting clr-namespaces. Actually my “fix” didn’t a darn thing except make sure it reads metadata haha. I will look into this. We’ll have to use some sort of type registration mechanism but in the case where you specify the type explicitly during deserialization we’ll hook into that and get the type(s) from there.

Indeed, our CI/CD kicks in and the MyGet feed gets updated with each commit… for better or for worse. 😆

The located assembly’s manifest definition does not match the assembly reference

Hmm… strange… does it say which assembly it’s having this issue?

Thank you for your prompt reply. I think you have been very successful in your aim to breathe new life into XML by supporting interface type serialization - you saved me a lot of hassle! 😄

Is the latest version available on the myget feed?

I tried cloning the repo and referencing a release build on my local machine but I am getting the following error in my project:

The located assembly's manifest definition does not match the assembly reference

FYI, I am using .net core 2.0 and registering the dependency as a transient service in Startup.cs.

hah! Well TBH our focus has been mostly on object graph serialization in the XML format, rather than being XML-standards compliant or sticking strictly to the specification. We do certainly strive for sticking to the specification but we’re aiming to breathe new life into XML while also supporting legacy scenarios within reason. There are items such as #159 that no longer seem applicable. Mostly in my case I just wanted an XML serializer that will serialize .NET objects no questions asked. There were a lot of questions that had to be answered to get to that point though. 😉

But yes, metadata-support for name/space resolution is certainly a reasonable expectation. We had it working somewhat but it wasn’t being used for namespaces. Now it is though. 😎 Please check out the latest and see how it treats you.