| Description
| - The information in this post is out of date. Visit msdn.com/data/ef for the latest information on current and past releases of EF. For Configuration File Settings se http://msdn.com/data/jj55660 We recently released Entity Framework 4.3 Beta 1 which includes the ability to configure more DbContext and Code First related settings from your applications Web.config or App.config file. These Settings are Optional Code First and the DbContext API follow a ‘convention over configuration’ principle. All the settings discussed in this post have a default behavior, you only need to worry about changing the setting when the default no longer satisfies your requirements. All of these settings can also be applied using code. The configuration file option allows these settings to be easily changed during deployment without updating your code. The Entity Framework Configuration Section In earlier versions of Entity Framework you could set the database initializer for a context using the appSettings section of the configuration file. In EF 4.3 we are introducing the custom entityFramework section to handle the new settings. Entity Framework will still recognize database initializers set using the old format, but we recommend moving to the new format where possible. The entityFramework section was automatically added to the configuration file of your project when you installed the EntityFramework NuGet package. Connection Strings Setting a connection string for a context uses the same syntax as previous releases of Entity Framework. Code First uses normal ADO.NET connection strings. For example: This post provides more details on how Code First determines the database to be used, including connection strings in the configuration file. The Database First and Model First approaches with an EDMX file use special EF connection strings. For example: Connection strings go in the standard connectionStrings element and do not require the new entityFramework section. Code First Default Connection Factory The new configuration section allows you to specify a default connection factory that Code First should use to locate a database to use for a context. The default connection factory is only used when no connection string has been added to the configuration file for a context. To set a connection factory, you specify the assembly qualified type name in the deafultConnectionFactory element. Note: An assembly qualified name is the namespace qualified name, followed by a comma, then the assembly that the type resides in. You can optionally also specify the assembly version, culture and public key token. Here is an example of setting your own default connection factory: The above example requires the custom factory to have a parameterless constructor. If needed, you can specify constructor parameters using the parameters element. For example, the SqlCeConnectionFactory, that is included in Entity Framework, requires you to supply a provider invariant name to the constructor. The provider invariant name identifies the version of SQL Compact you want to use. The following configuration will cause contexts to use SQL Compact version 4.0 by default. If you don’t set a default connection factory, Code First uses the SqlConnectionFactory, pointing to .\SQLEXPRESS. SqlConnectionFactory also has a constructor that allows you to override parts of the connection string. If you want to use a SQL Server instance other than .\SQLEXPRESS you can use this constructor to set the server. The following configuration will cause Code First to use a LocalDB instance for contexts that don’t have an explicit connection string set. By default, it’s assumed that constructor arguments are of type string. You can use the type attribute to change this. Database Initializers Database initializers are configured on a per-context basis. They can be set in the configuration file using the context element. This element uses the assembly qualified name to identify the context being configured. By default, Code First contexts are configured to use the CreateDatabaseIfNotExists initializer. There is a disableDatabaseInitialization attribute on the context element that can be used to disable database initialization. For example, the following configuration disables database initialization for the Blogging.BlogContext context defined in MyAssembly.dll. You can use the databaseInitializer element to set a custom initializer. Constructor parameters use the same syntax as default connection factories. You can configure one of the generic database initializers that are included in Entity Framework. The type name should specify your context as the TContext generic. The type attribute uses the .NET Framework format for generic types. The following configuration sets the DropCreateDatabaseAlways initializer for the BlogContext.Note: The type name is wrapped in the example but must appear on a single line in your configuration file. If you are using Code First Migrations, you can configure the database to be migrated automatically using the MigrateDatabaseToLatestVersion initializer.Note: The type name is wrapped in the example but must appear on a single line in your configuration file. Summary In this walkthrough you saw how to use the configuration file to set connection strings, default connection factory and database initializers. Rowan Miller Program Manager ADO.NET Entity Framework
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)
![[cxml]](/fct/images/cxml_doc.png)
![[csv]](/fct/images/csv_doc.png)
![[text]](/fct/images/ntriples_doc.png)
![[turtle]](/fct/images/n3turtle_doc.png)
![[ld+json]](/fct/images/jsonld_doc.png)
![[rdf+json]](/fct/images/json_doc.png)
![[rdf+xml]](/fct/images/xml_doc.png)
![[atom+xml]](/fct/images/atom_doc.png)
![[html]](/fct/images/html_doc.png)