An addition to @Oded, you can make the method Generic aswell: public T ConvertXml<T>(string xml) { var serializer = new XmlSerializer(typeof(T)); return (T)serializer.Deserialize(new StringReader(xml)); } This way you don’t need to make the whole class generic and you can use it like this: var result = ConvertXml<MyObject>(source);
I don’t know if this is related at all, but I had an issue with XSLT and found those rather interesting comments by Microsoft about the 64-Bit JITter: The root of the problem is related to two things: First, the x64 JIT compiler has a few algorithms that are quadratically scaling. One of them is … Read more
I find the answer here: Xmlserializer – Control Element-Attribute Pairing (revised). Here is how to do it: mark the value property with the [XmlText] attribute. public class Quantity { // your attributes [XmlAttribute] public string foo; [XmlAttribute] public string bar; // and the element value (without a child element) [XmlText] public int qty; }
Mark your class with the following attributes: [XmlType(“Account”)] [XmlRoot(“Account”)] The XmlType attribute will result in the output requested in the OP. Per the documentation: Controls the XML schema that is generated when the attribute target is serialized by the XmlSerializer
This worked for me: [XmlInclude(typeof(BankPayment))] [Serializable] public abstract class Payment { } [Serializable] public class BankPayment : Payment {} [Serializable] public class Payments : List<Payment>{} XmlSerializer serializer = new XmlSerializer(typeof(Payments), new Type[]{typeof(Payment)});
It looks like this is a very old XmlNodeReader bug that Microsoft have no intention of fixing. (Archived Microsoft Connect link here). I found a workaround on Lev Gimelfarb’s blog here that adds namespaces to the reader’s NameTable as prefixes are looked up. public class ProperXmlNodeReader : XmlNodeReader { public ProperXmlNodeReader(XmlNode node) : base(node) { … Read more
Configuring the below values solved the problem for me. Client Config: <system.serviceModel> <bindings> <basicHttpBinding> <binding name=”BasicHttpBinding_IManagementService” closeTimeout=”00:01:00″ openTimeout=”00:01:00″ receiveTimeout=”00:10:00″ sendTimeout=”00:01:00″ allowCookies=”false” bypassProxyOnLocal=”false” hostNameComparisonMode=”StrongWildcard” maxBufferSize=”2147483647″ maxBufferPoolSize=”524288″ maxReceivedMessageSize=”2147483647″ messageEncoding=”Text” textEncoding=”utf-8″ transferMode=”Buffered” useDefaultWebProxy=”true”> <readerQuotas maxDepth=”128″ maxStringContentLength=”2147483647″ maxArrayLength=”16384″ maxBytesPerRead=”4096″ maxNameTableCharCount=”16384″ /> <security mode=”None”> <transport clientCredentialType=”None” proxyCredentialType=”None” realm=”” /> <message clientCredentialType=”UserName” algorithmSuite=”Default” /> </security> </binding> </basicHttpBinding> </bindings> <client> <endpoint address=”http://XXXX/ManagementService.svc” … Read more
I have just reproduced that issue. As I wrote in comment. FileMode.Open erases contents of the file while FileMode.OpenOrCreate does not. It seems that new content of the file is one char shorter than previous that’s why you see “>” at the end. If you are writing the file use FileMode.Create that should do for … Read more
This is possible using the default infrastructure by making use of properties that return an object of type XmlComment and marking those properties with [XmlAnyElement(“SomeUniquePropertyName”)]. I.e. if you add a property to Foo like this: public class Foo { [XmlAnyElement(“VersionComment”)] public XmlComment VersionComment { get { return new XmlDocument().CreateComment(“The application version, NOT the file version!”); … Read more
You can use XmlSerializer as well, but you need to include all the possible types that can appear in the object graph you’re serializing, which limits extensibility and lowers maintainability. You can do it by using an overload of the constructor of XmlSerializer: var x = new XmlSerializer(animals.GetType(), new Type[] { typeof(Cat), typeof(Dog) }); Also, … Read more