To compare: In non-web projects, Visual Studio project files manage the locations of referenced assemblies. When a non-web project is built, Visual Studio looks into the project file and looks through its list of referenced assemblies. For each one, it compares the version in the local obj directory with the one located at the hint path in the project file. If it’s different, then the project can copy down the new version before it continues to build. This is how the projects can manage when “project references” and other references change.

*.refresh Files

Remember: No project files for web projects at this point. Because of this, the enlightened folks at Microsoft needed to come up with a new way to auto-update these assemblies. So whenever there’s a DLL reference that should be “dynamic” (updatable), Visual Studio adds a “refresh” file – a file with the same name, but ending in a “.refresh” extension. If you open this file in a text editor, you’ll see that it contains the original path of the DLL.

When a web application builds, Visual Studio goes through all the files in the project’s bin directory. If any of the files has an associated *.refresh file, Visual Studio will go out to the location specified by the *.refresh file and compares versions. If there’s a newer one at the *.refresh location, it’ll pull it down. Using the project code and the files in the bin directory, Visual Studio can calculate the project’s dependency tree. Every dependency must either be in the project’s bin directory, or in the Global Assembly Cache (GAC) for it to build successfully. If a file does not have a *.refresh file, then Visual Studio will not do this comparison, and the file is considered a static reference. Any static references will, be definition, not be updated automatically, so if you make a change to a DLL that the web site uses, and that DLL does not have a valid *.refresh file, then you’ll need to manually copy the new DLL file into bin directory for it to work.

Why Does It Take So Darn Long?

When a web site is run locally (F5), the IDE “validates” the site by looking at every single file in the “project” (the directory tree), locating all of the dynamic references (*.refresh files) and all of their dependencies so it can be sure they’re all living happily in the site’s bin directory, and compiling either the entire site (default), the current page, or nothing at all. (See Start Action, below.) Whenever there’s a change to the bin directory, the dependency tree needs to be recalculated and resolved to include whatever changes have been made. This can cause the build to slow down considerably especially when more than one version of the same assembly is being referenced. (Every time the new version is copied in, the bin has changed, which sparks the reference tree recalculation again.)

To speed things up a bit, you can remove some or all of the dynamic references by deleting the *.refresh files. Your build will be faster, but you’ll need to keep them updated if there are any changes, and you’ll need to store the DLLs in source control (because they’re not a static part of the project). You can also change the Start Action from Site (the default) to individual page, or even “No Build” to let ASP.NET compile on the fly. Finally you can consider a different type of web project model – one that isn’t an all-or-nothing approach to project contents. (See Web Site Projects, below.)