Hey, so I’m not sure what might have happened with your code but I think something might have gotten messed up since it looks like you have a class declaration inside a constructor. I’m not sure what that means… sorry!
Anyway, I don’t think you have to tell it it’s a derived class, you just have to tell XmlSerializer what type it’s going to be working with. So if your class inherits another, just use the type you want to deserialize and it should work. I did a quick test and everything seems to be ok on my end. I used the exact same code I pasted above, but instead used the following class:
[Serializable()]
public class Data
{
public string Text { get; set; }
public Vector2 Location { get; set; }
public override string ToString()
{
return string.Format("{{Text={0}, Location={1}}}", this.Text, this.Location.ToString());
}
}
[Serializable()]
public class DataExtended : Data
{
public int ExtraData { get; set; }
public override string ToString()
{
return base.ToString() + string.Format(" + {{ExtraData={0}}}", this.ExtraData.ToString());
}
}
Everywhere I used Data in the sample above, I just replaced it with DataExtended and everything worked out. I also tried a field in the class I’m serializing that was another class that I created, which looks like what you might be doing. This also seemed to work ok.
Maybe it would help if you told me what your goal was… like, what do you want to accomplish? Are you looking to persist and restore an instance of GameInit?
Thank you for the help. It is very frustrating because all this worked well before I updated to the latest versions. VS2017 & Monogame 3.6.
Let me explain what I am doing. I was trying to implement a form of Xaml for all my classes.
In my game, I have a base control called Control. On this control, I derive all the many objects of the game, buttons, screens, sliders, links, textboxes, etc. Each control has an init class that contains all the parameters of the control, i.e. size, location, color. etc.
Each game is made up of screens that are an hierarchy of controls that are initialized from xml. At the start of the game I deserialize GameInit which contains the parameters of the game and a control called XLink that links to the first screen of the game. The first screen is usually a main menu made up of a series of buttons. A button is a control that has attached to it an XLink to some screen and so on.
I was in the process of developing a control editor. Much like a level editor but for controls. Then I would be able to create a game by editing controls. To start I have developed a series of card game controls that will allow me to create any solitaire game.
Hope this helps.
Well, do I apologize for inanity.
<XLinkInit xsi:type="XLinkInit">
will not deserialize into this
public XLinkInit xlink
{ get; set; }
but this will
<xlink xsi:type="XLinkInit">
The name in the xml has to agree with the object name.
Somewhere along the way I must have lost an ElementName.
I do apologize.
Ok, so what you’re trying to do is quite normal, and should actually work! One different thing I notice is that you have the xsi:type attribute in your XML whereas mine didn’t… it just had the data type as the node name for the root, with the field name as the node name for any nested fields.
I suggested it before way back at the start and I’m going to throw it out there again. Maybe take a look at Json.Net. It’s a much cleaner approach and simpler to use. It’s quite well documented and available as a NuGet package that you can just download into your project
Both methods use a lot of reflection to restore the object, but I believe that Json.Net does it a little better. Maybe try a demo project with it and see if you like it better?
Thanks. I now have my project working.
A lot of my issues were to get the right assembly referenced. Not sure what others have found but VS gets very confused for some reason. I sorted it out by using the browse feature and many problems disappeared.
As to JSON, I will research it. But, I am pretty tired of retrofitting new technologies. It seems that every time I get some headway there is a new technology.
Thanks for your help.
Definitely understand… refactor after refactor can get a little tiresome 
For what it’s worth, following SOLID coding standards can really help mitigate the pain in the butt this can cause. By that I mean, ensure all your components are behind interfaces that you control, so that when you decide you want to try a new technology, you just have to change the one component, not your whole project. I dunno if you do this already but I figured I’d mention it 
Anyway, I’m glad you got it working!