I'm using this technology to manage my XML files as Databases. When I do this, normally I created the classes in a library and using XSD.exe I can get my XSD.

Then, with LinqToXSD and my new XSD generated, I can access to the data. This is my first class which should be in my program.

    public class Foo
    {
        string FirstName
        string LastName
    }

And to access the data I used this namespace

    urn.foo

And I realized, that they are two different classes, I mean I need to convert this class (urn.foo from XSD) into real Foo (the first one). So, I have two different classes, and I want to have just one!

This is just the way LinqToXSD (and probably most xml-to-object mappers) works.

LinqToXSD generates a class and methods for each xsd type and its attributes / content.

But if you look at the source code you will see they are defined as 'partial',
which means you can easily extend them using another file (so your extensions don't get overriden if you regenerate the classes from xsd).

To continue your example:

If you have

  <xsd:element name="Foo" type="Foo" />
  <xsd:complexType name="Foo">
     <xsd:attribute name="FirstName" type="xsd:string" />
     <xsd:attribute name="LastName" type="xsd:string" />
  </xsd:complexType>

then LinqToXSD will have generated somewhere in foo.cs:

public partial class Foo : XTypedElement, IXMetaData {
/* ...much more stuff... */    
    public string FirstName {
        get {
            return this.ContentField.FirstName;
        }
        set {
            this.ContentField.FirstName = value;
        }
    }
    
    public string LastName {
        get {
            return this.ContentField.LastName;
        }
        set {
            this.ContentField.LastName = value;
        }
    }

/* ...much more stuff... */    
}

and you could define in some aother file, lets say ExtendFoo.cs:

public partial class Foo
{
     public string FullName { 
         get {
            return this.FirstName + " " + this.LastName;
         }
     }
}

Hope that helps,

Daniel

Are you hand writing classes and then generating an XSD from the hand written classes?

And then are you creating class wrappers based on the XSD?

Because you won't ever be able to get LinqToXsd to instantiate your hand written classes from an Xml file.

Or write classes that cast to your hand written classes.

We have a similar situation, we have auto generated classes wrappers made by LinqToSql

And we have auto generated class wrappers made by LinqToXsd

In order to ease translating between the two, we use partial classes and extension methods to write handy helper methods for doing the convertion.

So if we have a SLUser class from LinqToSql and a BLUser class from LinqToXsd we write an extention method User.ToBLUser() and a partial method BLUser.ToSLUser()

If you really want it to flatten your own objects to Xml and vice versa, perhaps .NETs own Xml Serialization functionality would be better?