Keywords: Entity Framework 5 | ASP.NET MVC 4 | web.config configuration | type initializer exception | defaultConnectionFactory
Abstract: This article provides an in-depth analysis of the 'System.Data.Entity.Internal.AppConfig type initializer threw an exception' error that occurs when deploying Entity Framework 5 in ASP.NET MVC 4 projects to IIS. By examining web.config structure, it identifies the root cause of duplicate DbContext configuration and presents best-practice solutions. The paper discusses proper defaultConnectionFactory configuration, the importance of configuration file element ordering, and strategies to avoid common deployment pitfalls.
Problem Background and Error Analysis
When using Entity Framework 5 in ASP.NET MVC 4 projects, development environments typically function correctly, but runtime configuration exceptions may occur after deployment to IIS servers. The specific error reported by users is: The type initializer for 'System.Data.Entity.Internal.AppConfig' threw an exception, with detailed exception information indicating that the DbContext type GdpSoftware.Server.Data.GdpSoftwareDbContext is specified multiple times in the application configuration.
Root Cause of Duplicate Configuration Issues
Entity Framework 5 reads the <entityFramework> configuration section from the web.config file during initialization. When the same DbContext type is defined multiple times in the configuration file, the framework cannot determine which configuration to use, leading to type initialization failure. This problem typically occurs in the following scenarios:
- The project references multiple assemblies containing EntityFramework configurations
- The web.config file is incorrectly merged or modified during the publishing process
- Configuration section handler definitions are incorrect
Core Solution: defaultConnectionFactory Configuration
According to the best practice answer, the key to resolving this issue lies in correctly configuring defaultConnectionFactory. In the provided web.config example, although <defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework" /> is defined, it may lack necessary parameter configuration.
The correct configuration method should explicitly specify connection string parameters:
<entityFramework>
<defaultConnectionFactory type="System.Data.Entity.Infrastructure.SqlConnectionFactory, EntityFramework">
<parameters>
<parameter value="Data Source=ServerAddress;Initial Catalog=DatabaseName;User ID=Username;Password=Password" />
</parameters>
</defaultConnectionFactory>
<contexts>
<context type="GdpSoftware.Server.Data.GdpSoftwareDbContext, GdpSoftware.Server.Data" disableDatabaseInitialization="true">
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[GdpSoftware.Server.Data.GdpSoftwareDbContext, GdpSoftware.Server.Data], [GdpSoftware.Server.Data.Migrations.Configuration, GdpSoftware.Server.Data]], EntityFramework" />
</context>
</contexts>
</entityFramework>
Configuration File Structure Optimization
As supplementary reference, another answer emphasizes the importance of configuration file element ordering. In ASP.NET configuration files, <configSections> must be the first child element of <configuration>, followed by <connectionStrings>, then <startup> and other elements. This order ensures that configuration section handlers are properly registered before other configuration sections are parsed.
Example structure:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<configSections>
<section name="entityFramework" type="System.Data.Entity.Internal.ConfigFile.EntityFrameworkSection, EntityFramework, Version=5.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" requirePermission="false" />
</configSections>
<connectionStrings>
<add name="GdpSoftwareConnectionString" connectionString="Persist Security Info=False;User ID=user;Password=password;Initial Catalog=databasename;Data Source=server" providerName="System.Data.SqlClient" />
</connectionStrings>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<!-- Other configuration sections -->
</configuration>
Deployment Considerations
When deploying projects to IIS, the following key points should be noted:
- Version Consistency: Ensure the .NET Framework version on the server matches the project target framework (4.5 in this case).
- Assembly Binding Redirects: Check
<assemblyBinding>configuration in the<runtime>section to ensure correct versions of EntityFramework and related dependency assemblies. - Connection String Validation: Connection strings may need adjustment based on server environment after deployment, particularly database server addresses and authentication information.
- Configuration Transformation: Use Web.config transformation files (such as Web.Debug.config and Web.Release.config) to manage configuration differences across environments.
Debugging and Verification Steps
When encountering similar configuration issues, follow these debugging steps:
- Enable detailed error information in web.config (as in the example
<customErrors mode="Off" />). - Use IIS Failed Request Tracing to record configuration loading processes.
- Add configuration validation code during application startup to check if EntityFramework configuration sections are loaded correctly.
- Compare web.config files between development and production environments to identify differences.
Summary and Best Practices
Entity Framework 5 configuration issues typically stem from structural errors or content duplication in configuration files. By following these best practices, most deployment problems can be avoided:
- Maintain standard ordering of configuration file elements
- Explicitly configure
defaultConnectionFactorywith its parameters - Ensure each DbContext type is defined only once in configuration
- Use configuration transformations to manage environment differences
- Thoroughly test configuration validity before deployment
Understanding Entity Framework's configuration mechanisms not only helps resolve current issues but also provides a solid foundation for more complex application scenarios. Proper configuration management is crucial for ensuring application stability across different environments.