Visual Studio Web Project Files under Source Control
Some of the files that you work with in a Web project require special consideration when working with source code control.
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 Studio make changes to the Web.config file. For example, if you use the Visual Studio 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 Studio 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.
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.
Like the Web.config file, the Global.asax file stores information that applies to the entire Web site and is located in the root of the Web site. 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 (.resx) files store information in XML format. Resource files can be either local to a page or global to the Web project. 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.
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.
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.
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 Studio 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 binary files, or about building and overwriting source controlled versions.