Web Site Files under Source Control

  • Article

Some of the files that you work with in a Web site require special consideration when working with source code control.

Web.config File

Because the Web.config file is a central store for application-wide configuration settings, it is more likely than individual pages to be checked out to multiple developers at the same time. As long as different developers are not changing the same settings at the same time, the merge functionality of the source control system can incorporate the changes during the check-in process.

You can open the Web.config file manually to edit it. In that case, you can explicitly check the file out first or rely on implicit checkout when you make edits to the file, as you would with an ASP.NET page. In addition, a number of utilities in Visual Web Developer make changes to the Web.config file. For example, if you use the Visual Web Developer Add Reference dialog box to create a reference to a client project, a Web service, or an assembly in the Global Assembly Cache (GAC), the new reference is stored in the Web.config file. In most cases, Visual Web Developer will automatically check out the Web.config file as needed. For example, if you add a new reference to your Web application, and if you do not have the Web.config file checked out, the Add Reference command will check Web.config out and add the reference.

However, not every process that affects the Web.config file automatically checks it out. The following is a list of utilities that require you to check out the Web.config file before editing your application's configuration:

  • The Web Site Administration Tool (ASP.NET Configuration command on the Web site menu) does not check out the Web.config file automatically. If you try to save changes in the Web Site Administration Tool without first checking out the Web.config file, the tool displays an error indicating that the Web.config file is read-only. The solution is to explicitly check out the Web.config file before using the Web Site Administration Tool.

  • The ASP.NET MMC snap-in does not check out the Web.config file automatically, and it will display an error if you try to save configuration changes before checking out the file.

Encrypted Sections of the Web.config File

If you have configured the Web.config file with encrypted sections, merging is no longer possible. Unencrypt configuration settings before merging.

For details about encrypting sections of the Web.config file, see Encrypting Configuration Information Using Protected Configuration.

Global.asax File

Like Web.config, the Global.asax file stores information that applies to the entire Web site and is located in the root of the Web site. Specifically, the Global.asax file contains event-handling code for events that are raised for the application or session. In general, multiple developers can safely check out the Global.asax file and rely on the source control provider's merge facility to resolve conflicts at check-in.

Resource Files

Resource (.resx) files store information in XML format. Resource files can be either local to a page or global to the Web application. A local page resource file is stored in the App_LocalResources file using a name that is based on the name of the page with which it is associated. For example, the page Default.aspx will have a corresponding local resource file named Default.aspx.resx. Global resource files are stored in the App_GlobalResources file. You can assign any name to these files as long as they contain the .resx file name extension.

Local resource files are not automatically checked out when you check out a page. Therefore, you must check out the corresponding resource file, either explicitly or implicitly, before editing it. Working with global resource files is similar, except that the likelihood of contention between developers can be higher. Before checking out a page that relies on a global resource file, check source control to see if someone else has the global resource file checked out.

In both cases, because the resource file is in XML format, conflicts during check in can be resolved by merging.

Application Services Database

If you use ASP.NET membership, role management, or profiles, application information for these services is stored in a database. By default, the database is local to the Web application, and it is stored as a database file in the App_Data folder of your Web application. The services also require entries in the Web.config file. For more information, see Creating and Configuring the Application Services Database for SQL Server.

Storing application data in a local database can cause problems if your Web site is under source control for these reasons:

  • Each developer must check out the database file when locally debugging the application. You cannot debug your application with a read-only version of the database file; a read-only database file results in run-time errors.

  • The database is stored in the source control repository as a binary file. Consequently, the source control system cannot merge changes if multiple developers have the database file checked out. Instead, each developer's check-in overwrites the previous version.

When working with a Web application that is under source control, it is best to use a shared database file that is not under source control to store application services data. For example, you can use a central server running Microsoft SQL Server for application data. All developers are then working with the current, live data. You can then also use the database's backup facilities to manage the application data. For details about selecting a database for application data, see Creating and Configuring the Application Services Database for SQL Server.

Assembly Files

You can add assemblies (.dll files) to your Web site's Bin folder and then reference the assemblies in your code. You do not need to check out a .dll file unless you want to overwrite it with a newer version.

Source control systems cannot merge changes if two or more developers change the binary .dll file at the same time. Therefore, as a best practice you should not allow multiple checkouts on a .dll file if you intend to update the file and check it back in. You can set an option during checkout to prevent others from checking the file out while you have it.

References to Client or Class Library Projects

While working with your Web application, you can add a client or class library project to the solution and create compilable components in the library project. You can then create a project-to-project reference in your Web application to reference the compiled output of the library project. For example, when creating a class library project, you might create an assembly with utility classes or custom controls within the project and then reference those assemblies in your Web application.

When you create a reference to another project, Visual Web Developer copies compiled output from that project if it exists. For that reason, you need to build a project before you can create a reference to it from another project. Compiled output from client projects is not under source control; therefore, developers do not need to worry about deleting old versions of binaries, or building and overwriting source controlled versions.

See Also

Concepts

Web Site Source Control Overview

Other Resources

Creating and Configuring the Application Services Database for SQL Server