Microsoft ASP. NET site deployment guide (3): Use Transformations in the Web. Config file

1. Summary

In most programsWeb. configAnd must be changed during deployment. It is tedious and error-prone to manual configuration changes every time. This section will tell you how to update automaticallyWeb. configFile to avoid these problems.

2. Web. config Transformations and Web Deploy Parameters

There are two ways to automatically update the settings of the Web. config file: Web. config transformations and Web Deploy parameters. The Web. config transformation file contains the XML tag to be updated during deployment. You can declare different updates for different build configurations. The default build configurations are Debug and Release. You can also create custom build configurations.

 

Web Deploy parameters can define any more settings required for deployment (as long as they can be defined in Web. config ). Creating Web Deploy parameters when defining Web. config file updates is very complicated, but it is very useful if you only know these configuration values during deployment. For example, in some enterprise environments, If You package the program and send IT to people in the IT department to install IT in the production environment, the IT personnel need to enter a string to connect or cannot get your password.

You can configure anything in Web. config in advance, so you do not need to use the Web Deploy parameters method.

Reminder: check the Troubleshooting page if an error message or some functions are abnormal during operations in this section.

3. Create a new Build Configuration

You have two goals to deploy: test environment and production environment. When deployed to the test environment, the Release version is generally deployed instead of the Debug version. However, some Web. config parameters may be different from those in the production environment. Because Web. config transformations is declared by build configuration, you need to create a build configuration for the test environment.

 

The production environment uses the default Release build configuration. If you can use debug in the testing environment, you can also use the default Debug build configuration. If you need to deploy the Release version program in the Test environment, you can create a Test build configuration.

Open the Visual Studio Build menu and select Configuration Manager to bring up the Configuration Manager dialog box.

 

InActive solution configurationBox, select newNew. Pop-upNew Solution ConfigurationDialog box, enter "Test" as the name of the new build configuration, and then selectReleaseCopy settings. SaveCreate new project deploymentsSelect, and then clickOK.

 

CloseConfiguration ManagerDialog box.

You also needWeb. configThe transform file corresponds to the Test build configuration. InSolution Explorer, ExpandWeb. configFile to see the default createdWeb. Debug. configAndWeb. Release. configFile, right-clickWeb. configThen selectAdd Config Transforms.

 

The Web. Test. config file is successfully added.

 

Now, you can enter Web. config transformations to the Web. config transformation file.

4. Prevent Entity Framework Code First from deleting production environment Databases

In the development environment, Entity Framework Code First is usually configured to automatically delete/recreate databases when the data model changes. It is very convenient when you develop the site and frequently change the data model, but you certainly don't want it to happen in the production environment. The recommended method for controlling the automatic database initialization function of Entity Framework is to set the value of appSettings in the Web. config file.

 

(We recommend that you set the Code in the Application_Start method of the Global. asax file in the early Code First tutorial. If you have such Code, delete it before deployment. Because Code First can be controlled without changing the project, for example, you can configure a test project for database initialization .)

Web. configFileappSettingsSetDatabaseInitializerForType.

<appSettings>
  <add key = "DatabaseInitializerForType ContosoUniversity.DAL.SchoolContext, ContosoUniversity.DAL"
    value = "ContosoUniversity.DAL.SchoolInitializer ContosoUniversity.DAL" />
  <!-Other settings->
</ appSettings>
 

You need to modify the value attribute value to "Disabled" for the configuration of the deployment site, as follows:

<appSettings>
  <add key = "DatabaseInitializerForType ContosoUniversity.DAL.SchoolContext, ContosoUniversity.DAL"
    value = "Disabled" />
  <!-Other settings->
</ appSettings>
 

Open Web.Release.config and immediately add a new appSettings element as follows (make sure to add only appSettings element).

<configuration xmlns: xdt = "http://schemas.microsoft.com/XML-Document-Transform">
  <appSettings>
    <add key = "DatabaseInitializerForType ContosoUniversity.DAL.SchoolContext, ContosoUniversity.DAL"
        value = "Disabled" xdt: Transform = "SetAttributes" xdt: Locator = "Match (key)" />
  </ appSettings>
  <!-Existing comments and system.web element->
</ configuration>
 

The xdt: Transform attribute value "SetAttributes" means that the purpose of the current transform is to update elements that already exist in the Web.config file. The xdt: Locator attribute value "Match (key)" means that the key attribute of the element to be updated is the same as the currently declared key attribute, and the other value is the value that needs to be modified in the deployment Web.config file. This code will set the Entity Framework Code First initializer to "Disabled".

 

If the test environment and the production environment use the same configuration, that is, only the development environment can automatically create the database, so you need to add the same code in the Web.Test.config file. (You do not need to update the Web.Debug.config file, because this chapter will not create any Debug build).

5. Restrict error log access (only authorized to Administrators)
If the program runs again with errors, the program will display a common error message (instead of the system yellow pages), use the Elmah NuGet package to process error logs and reports. The customErrors element of the Web.config file declares the address of the error page:

<customErrors mode = "RemoteOnly" defaultRedirect = "/ GenericErrorPage.aspx">
  <error statusCode = "404" redirect = "/ GenericErrorPage.aspx" />
</ customErrors>
 

To see the error page, temporarily set the mode value of the customErrors element to "On" and run the program from Visual Studio. Enter an illegal URL address (such as Studentsxxx.aspx), you can see the custom error page GenericErrorPage.aspx page instead of the "page not found" error page.

 

To view the error log, enter elmah.axd (the example is: http: // localhost: 51130 / elmah.axd) behind the port to access:

 

After reading it, don't forget to reset the mode value of the customErrors element to "RemoteOnly".

 

The development environment can access the error log page arbitrarily, but the production environment may be a security risk. For the production environment, you can restrict authentication by using only an administrator in the Web.Release.config file by adding a transform.

Open Web.Release.config and add the following code after the appSettings element:

<location path = "elmah.axd" xdt: Transform = "Insert">
  <system.web>
    <authorization>
      <allow roles = "Administrator" />
      <deny users = "*" />
    </ authorization>
  </system.web>
</ location>
 

The xdt: Transform attribute value "Insert" means to add this element to other nodes of the same type in Web.config as sibling nodes. (There is already a location element to declare the Update Credits page verification rules.) After the production environment is deployed, you need to test whether the verification is valid.

You don't need to restrict the access to the error log of the test environment, so you need to set up the Web.Test.config file.

Security Note: At no time should the error log information be displayed and maintained in the production environment. Hackers may use the vulnerability of the site to obtain this information. If you use ELMAH, make sure it is configured for minimum risk. The ELMAH configuration in this demo cannot be considered a recommended configuration. It is just an example for us to show how to control the permissions of a folder.

6. Set the environment identifier
It is common to see that different environments use different configurations. For example, if a program calls WCF, the endpoint addresses that may be called in different environments are different. The Contoso University program is similar. Setting a site identifier helps users easily know which environment site you are currently visiting. The Site.Master template file will display the head title with the identifier (Dev or Test) attached.

 

The identifier will be disabled when the production environment is running.

The Contoso University program page reads a value of appSettings in the Web.config file to determine which environment the currently running program is:

<appSettings>
  <!-Entity Framework initializer setting->
  <add key = "Environment" value = "Dev" />
</ appSettings>
 

This value should be "Test" in the test environment and "Prod" in the production environment.

Open the Web.Release.config file and add the following code to the appSettings element node:

<appSettings>
  <!-Entity Framework initializer transform that you entered earlier->
  <add key = "Environment" value = "Prod" xdt: Transform = "SetAttributes" xdt: Locator = "Match (key)" />
</ appSettings>
 

The Transform and Locator properties are similar to the Transform created earlier for Entity Framework.

After completion, the appSettings of Web.Release.config should look like this:

<appSettings>
  <add key = "DatabaseInitializerForType ContosoUniversity.DAL.SchoolContext, ContosoUniversity.DAL"
      value = "Disabled" xdt: Transform = "SetAttributes" xdt: Locator = "Match (key)" />
  <add key = "Environment" value = "Prod" xdt: Transform = "SetAttributes" xdt: Locator = "Match (key)" />
</ appSettings>
 

Next, the same code is applied to the Web.Test.config file, except that the value is set to "Test". After completion, the appSettings node under Web.Test.config should look like this:

<appSettings>
  <add key = "DatabaseInitializerForType ContosoUniversity.DAL.SchoolContext, ContosoUniversity.DAL"
      value = "Disabled" xdt: Transform = "SetAttributes" xdt: Locator = "Match (key)" />
  <add key = "Environment" value = "Test" xdt: Transform = "SetAttributes" xdt: Locator = "Match (key)" />
</ appSettings>
 

7. Disable Debug mode
For Release build, there is no need to enable debugging mode. By default, the Web.release.config transform file automatically removes the debug attribute from the compilation element. Because the Test build configuration you created is the setting copied from Release, Web.Test.config also has this code:

<system.web>
  <compilation xdt: Transform = "RemoveAttributes (debug)" />
</system.web>
 

The Transform attribute defines that the debug attribute is deleted from the Web.config file after deployment.

8. Set the connection string
Because we have 2 versions of the database, a development environment and a test and production environment, you need to set a different connection string for the test and production environment than the development environment. After opening Web.Test.config and the Web.Release.config file, add <connectionStrings> element in <configuration> as follows:

<connectionStrings>
  <add name = "DefaultConnection"
       connectionString = "Data Source = | DataDirectory | aspnet-Prod.sdf"
       providerName = "System.Data.SqlServerCe.4.0"
       xdt: Transform = "SetAttributes" xdt: Locator = "Match (name)" />
  <add name = "SchoolContext"
       connectionString = "Data Source = | DataDirectory | School-Prod.sdf"
       providerName = "System.Data.SqlServerCe.4.0"
       xdt: Transform = "SetAttributes" xdt: Locator = "Match (name)" />
</ connectionStrings>
 

The Match locator and SetAttributes transform attributes used by this code are similar to the environment identifier configuration above.

For the configuration of test and production environment, we are all set up. In the next chapter, you will learn to configure project properties.

9. More information
For this chapter For more information, please visit: ASP.NET Deployment Content Map and Can I exclude specific files or folders from deployment in the ASP.NET Web Application Project Deployment FAQ

 

Author Uncle Tom