Hi, On an ASP.NET application I have an upload box where a client and upload an XML file. This XML file is based on a ProcessEntity collection from another client application (Created with the WriteXML() of the entitycollection).

For the client application we needed to add a field (IndentLevel). I want to avoid updating the ASP.NET application and database, as it is already compiled and in its final release. Is it possible to put the [NotSerialized] attribute over this field so the server will still load it? Or is there more to it than that? I am not sure the server will read the xml correctly with the extra field.

I don't think the read xml will have any problems with extra fields, as I guess it will simply ignore them. Also you may try the NotSerialized attribute.

NotSerialized is remoting related, not XML related. If you want a field to not be serialized, use XmlIgnore(true) as attribute. However as this is already xml, I have no idea what you're trying to do or better: what you're trying to avoid, as I miss the info about what happens with the xml on the server

Heh

Well we have two applications here. We have a client rip off of Microsoft Project, and we have a web based document/project management portal. The client application can design out the project, then go to the website and upload the project. It works great, but we are in the process of writing our 2.0 version of BOTH, but the client application will be released first, and I'm hoping the server (version 1) will still be able to read the XML (from version 2).

Thanks for the help

Aha.

If an entity has a new property or field in v2, the property descriptor won't be found on the v1 entity. This then can lead to a crash as the code assumes both versions are the same. If the xml receiver was on v2 and the client on v1, it would work, but the other way around, it won't.

Otis wrote:

Aha.

If an entity has a new property or field in v2, the property descriptor won't be found on the v1 entity. This then can lead to a crash as the code assumes both versions are the same. If the xml receiver was on v2 and the client on v1, it would work, but the other way around, it won't.

Yeah it's crashing out on me now.

I'm out of options, the xml has to have the same xmlschema on both sides (serializing and deserializing).

Otis wrote:

I'm out of options, the xml has to have the same xmlschema on both sides (serializing and deserializing).

I came up with a hack for it already

Only one part of the web application needed to match this schema. So I generated another DAL called MissionFire.DALFIXED. Only one aspx page references this DAL, and it works out great. It's only a temp fix until 2.0 ships for the web application anyways.

Thanks for the help.

Glad you could work around it!

Remember what the old IT saying says though: "There's nothing more permanent as a temporary solution"