When DbContextInfo is created with known provider information--i.e. a DbProviderInfo object--it uses this provider information to build the model. However, if an ObjectContext is then requested it is created using the normal connection discovery mechanism. An exception is then thrown if the supplied provider info does not match the provider information from the connection.
This can happen with MVC scaffolding since it always uses the SqlClient provider to obtain c-space metadata and avoid the need to connect to the database to get a manifest token. So then when the normal connection discovery mechanism finds a non-SqlClient connection the exception is thrown.
The issue has always been present in MVC scaffolding and the workaround that people have been using is to replace the non-SQL Server connection string with a SQL Server connection string while scaffolding.
Anther workaround is to setup the default connection factory for the provider being used and then just comment out the real connection string while scaffolding. This works because if no connection is found in the app config then the default connection factory is used when creating the connection to create the ObjectContext.
This item was migrated from the DevDiv work item tracking system [ID=740670].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Exception:
```
Unhandled Exception: System.NotSupportedException: Using the same DbCompiledModel to create contexts against different t
ypes of database servers is not supported. Instead, create a separate DbCompiledModel for each type of server being used
.
at System.Data.Entity.Internal.CodeFirstCachedMetadataWorkspace.GetMetadataWorkspace(DbConnection connection) in c:\e
f\src\EntityFramework\Internal\CodeFirstCachedMetadataWorkspace.cs:line 64
at System.Data.Entity.Infrastructure.DbCompiledModel.CreateObjectContext[TContext](DbConnection existingConnection) in c:\ef\src\EntityFramework\Infrastructure\DbCompiledModel.cs:line 103
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext() in c:\ef\src\EntityFramework\Internal\LazyInternalContext.cs:line 417
at System.Data.Entity.Internal.InternalContext.Initialize() in c:\ef\src\EntityFramework\Internal\InternalContext.cs:line 485
at System.Data.Entity.Internal.InternalContext.ForceOSpaceLoadingForKnownEntityTypes() in c:\ef\src\EntityFramework\Internal\InternalContext.cs:line 1286
at System.Data.Entity.DbContext.System.Data.Entity.Infrastructure.IObjectContextAdapter.get_ObjectContext() in c:\ef\src\EntityFramework\DbContext.cs:line 341
at InvestigateContextInfo.Program.Main(String[] args) in c:\Stuff\InvestigateContextInfo\InvestigateContextInfo\Program.cs:line 51
```
Comments: Verified
This can happen with MVC scaffolding since it always uses the SqlClient provider to obtain c-space metadata and avoid the need to connect to the database to get a manifest token. So then when the normal connection discovery mechanism finds a non-SqlClient connection the exception is thrown.
The issue has always been present in MVC scaffolding and the workaround that people have been using is to replace the non-SQL Server connection string with a SQL Server connection string while scaffolding.
Anther workaround is to setup the default connection factory for the provider being used and then just comment out the real connection string while scaffolding. This works because if no connection is found in the app config then the default connection factory is used when creating the connection to create the ObjectContext.
This item was migrated from the DevDiv work item tracking system [ID=740670].
This work item originated from connect.microsoft.com. A member of the EF team at Microsoft should close the related Connect issue when closing this work item.
Exception:
```
Unhandled Exception: System.NotSupportedException: Using the same DbCompiledModel to create contexts against different t
ypes of database servers is not supported. Instead, create a separate DbCompiledModel for each type of server being used
.
at System.Data.Entity.Internal.CodeFirstCachedMetadataWorkspace.GetMetadataWorkspace(DbConnection connection) in c:\e
f\src\EntityFramework\Internal\CodeFirstCachedMetadataWorkspace.cs:line 64
at System.Data.Entity.Infrastructure.DbCompiledModel.CreateObjectContext[TContext](DbConnection existingConnection) in c:\ef\src\EntityFramework\Infrastructure\DbCompiledModel.cs:line 103
at System.Data.Entity.Internal.LazyInternalContext.InitializeContext() in c:\ef\src\EntityFramework\Internal\LazyInternalContext.cs:line 417
at System.Data.Entity.Internal.InternalContext.Initialize() in c:\ef\src\EntityFramework\Internal\InternalContext.cs:line 485
at System.Data.Entity.Internal.InternalContext.ForceOSpaceLoadingForKnownEntityTypes() in c:\ef\src\EntityFramework\Internal\InternalContext.cs:line 1286
at System.Data.Entity.DbContext.System.Data.Entity.Infrastructure.IObjectContextAdapter.get_ObjectContext() in c:\ef\src\EntityFramework\DbContext.cs:line 341
at InvestigateContextInfo.Program.Main(String[] args) in c:\Stuff\InvestigateContextInfo\InvestigateContextInfo\Program.cs:line 51
```
Comments: Verified