text: I have the following class:
  public class TextureData
  {
  public float FrameWidth;
  public float FrameHeight;
  }
  And I try to create an XML with it, like so:
  <?xml version="1.0" encoding="utf-8"?>
  <XnaContent xmlns:
  <Asset Type="TextureData">
  <FrameWidth>0.2</FrameWidth>
  <FrameHeight>0.2</FrameHeight>
  </Asset>
  </XnaContent>
  However, I'm getting the following error:
  error : Importer 'XmlImporter' had unexpected failure!
  1> Microsoft.Xna.Framework.Content.Pipeline.InvalidContentException: Could not resolve type 'TextureData'.
  Now in all the MonoGame tutorials about using XMLs with custom types, I always see they use external dll and add reference to it from the content root properties. I tried it, and it works. However, having to create additional project that generate external dll just so I can access a single class from XMLs seems very messy to me.
  So my question is - Is it possible to use XML and reference to a class that's defined in the same project, and not in external dll? I realize there might be sort of a chicken & egg problem (what compiles first, the content or the project), but I'm wondering if its still possible somehow.
  Thanks!
  The same type needs to be accessible by both the content pipeline and the game. This is why it goes into an assembly itself. You could try referencing the game executable from the content pipeline, but I cannot guarantee it will work.
  I don't fully grasp this yet, but are you reading the value in as the value to apply or are you using a switch statement?
  My assumption here is you are reading in the XML values and then using code to run the procedure, but you are applying the process via the code in the XML itself, perhaps try a switch statement with predefined code instead?
  Or have I something new to learn here?
  Also, should it not be " " and not ' '? or is that just what VS shows from debug data description information?
  Hmm...
  @KonajuGames
  You could try referencing the game executable from the content pipeline, but I cannot guarantee it will work.
  The content manager actually accept exe as a Reference. Surprising. However, it didn't work.
  Anyway if there's no proper way (eg something that is known to be supported and guaranteed to work) I'll just stick with the external dll, it isn't that bad I guess.
  BTW MonoGame is pretty awesome, so far its been a smooth, happy sail.
  @MrValentine
  Not 100% sure I understand you, but there's no need for switch statement you can just load it like this:
  TextureData panelData = content.Load<TextureData>("xml_file_name");
  And it match all the fields from the XML to the public members of TextureData. Does it answer your question or I totally misunderstood you?
  That's what I'm getting in the console output, type name is surrounded with ' and not ". Perhaps my compiled was replaced by an evil imposter?
  '
  "
  The content pipeline can take a XML file in a format like the above ("XnaContent") and build it into a binary XNB file. Then you can load it through the ContentManager like any other XNB file and get an object of the type specified in the XML file. To do the building of the XML to a XNB file, the content pipeline needs to be able to use reflection on the type, so it needs to be able to access the type in an assembly. To load the object, the ContentManager also needs to use reflection on the same type, so the game also needs to reference the same assembly.
  That is what I mean, when you say 'match', what is your process for matching? I suspect that is where the type error is occurring...
  Dunh Dunh Duuuuuuuuh
  I think @KonajuGames answered it perfectly. From the user side it just create an instance of the object, no additional code is needed. And like he explained, the content pipeline need the object's assembly to be able to do so.
  Personally I find it to be a great way to attach additional data to textures and sprites, like animation steps. Instead of init sprite animations hard-coded or making up my own format, I just add that as an XML (still working on it so I hope it will work as expected). I also believe it will allow users to later change the sprites and their metadata, so they can create alternative improved animations etc, making the game more mod-friendly.