none
Wrong storage provider being loaded when .EDMX file reopened.

    Question

  • I'm developing a storage provider, OdbcClient,  for the Entity Framework. Using this ADO.NET provider on top of our own ODBC driver, I can successfully create a .edmx file using the Entity Data Model Wizard in Visual Studio 2008 (Version 9.0.21002.8 RTM) from the sample NorthwindEF database. If I close my project, reopen it and double click on the Model1.edmx file, I get an error "Error 168: The provider did not return a ProviderManifest instance. Could not determine store version; a valid store connection or a version hint is required."

    The CLR Profiler shows that SqlProviderServices::GetDbProviderManifest(string) is being called, not my provider's implementation of DbProviderServices::GetDbProviderManifest. I cannot see why the OdbcClient is not being used and why the SqlClient is used instead?

    The App.config file (as generated by Visual Studio) contains (UID/PWD changed):

    Code Snippet

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <connectionStrings>
        <add name="NorthwindEFEntities" connectionString="metadata=.\Model1.csdl|.\Model1.ssdl|.\Model1.msl;provider=OpenLink.Data.OdbcClient;provider connection string=&quot;DSN=a801-sqlexpress-localhost;UID=xx;PWD=yy;&quot;" providerName="System.Data.EntityClient" />
      </connectionStrings>
    </configuration>



    My Model1.edmx file includes:
       ...
       <EntityContainer Name="NorthwindEFEntities">
       ...

    What's going wrong?
    Thanks

    Thursday, February 14, 2008 6:02 PM

Answers

  •  

     

    Hi Carl -

     

    Good news:  I found out why you're seeing the incorrect provider associated with your EDMX.

     

    Try the following work-around: 

          1.  Start Visual Studio.

          2.  Open your solution/project that contains the EDMX file.

          3.  Immediately close the solution (via "File|Close Solution".  Don't close VS, just close the solution)

          4.  re-open the solution inside VS.

     

    What is happening is an exception is being thrown the first time we load a project in a new VS process, and this breaks our logic in how we find the provider for your EDMX (when we can't find the provider, we default to SQL Server).  I've verified that this issue is fixed in current internal builds.

     

    Let me know if you have any more questions/problems.

     

    Thanks,

     

    Mike Kaufman

    Microsoft Corp.  

     

    Wednesday, March 12, 2008 8:09 PM

All replies

  •  

    Hi -

     

    Can you provide us with the call stack below SqlProviderServices::GetDbProviderManifest(string)?  This will help us in determining where this is being called from.

     

    Thanks,

     

    Mike Kaufman

    Microsoft Corp.

    Thursday, February 14, 2008 6:31 PM
  • Mike,

    I've uploaded a zip file (ftp://download.openlinksw.com/support/cblakeley/devenv_wrong_manifest_retrieved.zip) containing

    • App.config file
    • Model1.edmx
    • CLR Profiler 2.0 log

    If you search the call graph for GetDbProviderManifest, you should see that DbProviderServices::GetDbProviderManifest calls SqlProviderServices::GetDbProviderManifest. I can't see a call to OdbcClient::GetDbProviderManifest, which is what I would have expected.

     

    Thanks

    Carl Blakeley

    Friday, February 15, 2008 3:21 PM
  •  

     

    Hi Carl -

     

    I'm unable to access to zip file you posted (my connection just times out). 

     

    Can you please contact me offline (mkaufman --at-- microsoft --dot-- com).  If possible, I'd like to get a copy of your provider and run it under the debugger.  I should then be able to tell where this is getting called from & why.  

     

    Thanks a lot,

     

    Mike Kaufman

    Microsoft Corp.

    Monday, February 18, 2008 11:36 PM
  •  

     

    Hi Carl -

     

    Good news:  I found out why you're seeing the incorrect provider associated with your EDMX.

     

    Try the following work-around: 

          1.  Start Visual Studio.

          2.  Open your solution/project that contains the EDMX file.

          3.  Immediately close the solution (via "File|Close Solution".  Don't close VS, just close the solution)

          4.  re-open the solution inside VS.

     

    What is happening is an exception is being thrown the first time we load a project in a new VS process, and this breaks our logic in how we find the provider for your EDMX (when we can't find the provider, we default to SQL Server).  I've verified that this issue is fixed in current internal builds.

     

    Let me know if you have any more questions/problems.

     

    Thanks,

     

    Mike Kaufman

    Microsoft Corp.  

     

    Wednesday, March 12, 2008 8:09 PM
  • This work-around did the trick for me

     

    Tuesday, April 29, 2008 11:14 PM