locked
$metadata namespaces inconsistent in .NET 4 RC RRS feed

  • Question

  • The $metadata responses in .NET 4 specifies different namespaces depending on the provider used:
    Reflection provider: xmlns="http://schemas.microsoft.com/ado/2006/04/edm"
    Entity Framework Provider: xmlns="http://schemas.microsoft.com/ado/2008/09/edm"

    This causes problems when parsing the metadata via LINQ to XML because my client is agnostic of the provider used:
    Imports <xmlns="http://schemas.microsoft.com/ado/2006/04/edm">
    'Imports <xmlns="http://schemas.microsoft.com/ado/2008/09/edm">
    Dim schemaXml = XElement.Load(IO.Path.Combine(dataSourceUri.OriginalString, "$metadata"))
    Dim entityTypes = From e In schemaXml...<EntityType>
                              Select New With {
                                .Name = e.Attribute("Name").Value,
                                .NavigationProperties = From np In e...<NavigationProperty>
                               Select New With {.Name = np.Attribute("Name").Value}
                               }

    Does anybody have an idea how to work around this?

    Wednesday, March 3, 2010 7:07 PM

Answers

  • Hi,

    The namespace denotes the version of EDM used in the $metadata response. In .NET 4 the EF provider always uses EDM version 2 because it simply returns the EDM used by the underlying EF model.
    Reflection provider on the other hand uses the lowest EDM version which can express the features used by the specified mode. In your case it seems to be EDM version 1. If you would use for example a service operation whith void return type, that version would be raised to EDM 1.1. Other providers might raise it to 2.0 (for example for open types support) and so on.

    The namspaces are different because the schema od the EDM file changes version to version.
    If you need your client to be version agnostic and it's OK that it will work on the best quess bases, I would suggest you look at the namespace of the Schema element and verify it's one of those you recognize. If so, then simply use that namespace to process the rest of the document. Unfortunately you won't be able to use the nice VB syntax with Imports and <elementname>. You could instead declare a variable edmNamespace of type XNamespace which would hold the namespace value and then instead of the shortened sytnax like e...<child> you would call e.Descendants(edmNamespace + "child").

    The other approach might be to rewrite the document to use the same namespace, but that's a bit slower, although it would allow you to use the nice VB syntax then.

    Thanks,
    Vitek Karas [MSFT]
    Thursday, March 4, 2010 9:41 AM
    Moderator

All replies

  • Hi,

    The namespace denotes the version of EDM used in the $metadata response. In .NET 4 the EF provider always uses EDM version 2 because it simply returns the EDM used by the underlying EF model.
    Reflection provider on the other hand uses the lowest EDM version which can express the features used by the specified mode. In your case it seems to be EDM version 1. If you would use for example a service operation whith void return type, that version would be raised to EDM 1.1. Other providers might raise it to 2.0 (for example for open types support) and so on.

    The namspaces are different because the schema od the EDM file changes version to version.
    If you need your client to be version agnostic and it's OK that it will work on the best quess bases, I would suggest you look at the namespace of the Schema element and verify it's one of those you recognize. If so, then simply use that namespace to process the rest of the document. Unfortunately you won't be able to use the nice VB syntax with Imports and <elementname>. You could instead declare a variable edmNamespace of type XNamespace which would hold the namespace value and then instead of the shortened sytnax like e...<child> you would call e.Descendants(edmNamespace + "child").

    The other approach might be to rewrite the document to use the same namespace, but that's a bit slower, although it would allow you to use the nice VB syntax then.

    Thanks,
    Vitek Karas [MSFT]
    Thursday, March 4, 2010 9:41 AM
    Moderator
  • Thank you for this very clear and helpful answer.
    Thursday, March 4, 2010 7:32 PM