In my last blog entry, I covered the new ASP.net 2.0 solution structure and compilation model. In this article, I am going to cover some of the specifics of using MSBuild with the ASP.net compiler, and some of the issues I have with using it. Note that this article refers to the December CTP drop of Whidbey, so hopefully these issues will be resolved when beta 2 gets released.
MSBuild ships with version two of the .Net Framework and provides a command line tool to automate the build process, similar to previous tools such SDC Build tools and NAnt. The tool processes the contents of an XML file which complies with the MSBuild schema. In Visual Studio 2005, the project files that are contained in a solution are actually in MSBuild format, which provides you with the ability to edit the project files to change the behavior of the build of the projects within your solution.
Whilst project files are in MSBuild format, solution files are not. Now this presents a problem with ASP.net websites in Visual Studio 2005, as project files are no longer used. You can run a solution file through MSBuild, but this means that you cannot edit the behavior of the file, and there is also a bigger problem…
When you build a solution file in Visual Studio 2005 that contains an ASP.net web site, the solution builds as you would expect. However, if you build this solution in MSBuild, with projects referenced from the ASP.net website, you may get unexpected results.
Below is a section from the top of a solution file:
Microsoft Visual Studio Solution File, Format Version 9.00
# Visual Studio 2005
Project("{E24C65DC-7377-472B-9ABA-BC803B73C61A}") = "C:\...\MYSOLUTION.Web\", "..\..\WebSites\MYSOLUTION.Web", "{F43012E8-4502-4D3E-8CFD-191473919F20}"
ProjectSection(WebsiteProperties) = preProject
SccProjectName = ""$/MYSOLUTION.root/MYSOLUTION", CAAAAAAA"
SccAuxPath = ""
SccLocalPath = "..\.."
SccProvider = "MSSCCI:Microsoft Visual SourceSafe"
ProjectReferences = "{3B4929F7-AE08-4F2B-A685-1772AD635855}|MYSOLUTION.Business.Process.dll; "
AspNetCompiler.VirtualPath = "/MYSOLUTION"
AspNetCompiler.PhysicalPath = "..\..\WebSites\MYSOLUTION.Web\"
AspNetCompiler.TargetPath = "..\..\..\..\..\..\Output\MYSOLUTION\"
AspNetCompiler.Updatable = "true"
VWDPort = "27911"
EndProjectSection
You can see that there are a number of entries for the ASP.net compiler: virtual path, physical path, target path and updatable setting. These map directly to the arguments supplied to the ASP.net compiler command line tool (aspnet_compiler.exe) to precompile a web site. Just above this line, you can see a ProjectReferences entry. The ASP.net compiler uses this entry to compile the website against referenced assemblies. Notice that this reference is made against a file path and not against the project. This causes a problem for the ASP.net compiler when used through MSBuild, because the ASP.net compiler does not refresh the references to the assemblies stored in its \application_assemblies directory, and if the referenced projects are not built and copied to the website before the site is built, you can end up referencing an out of date assembly, causing build failure.
To get around this issue when needing to build the site outside of Visual Studio (such as on a continuous integration server such as Cruise Control), you will need to create a custom MSBuild script to ensure that the site is compiled after the referenced projects, and that these assemblies are copied to the application_assemblies directory. The following exert from an MSBuild script illustrates the tasks required to ensure that the ASP.net site compiles against the last version of the referenced assemblies:
<!-- build projects-->
<MSBuild Projects="$(WorkingDirectory)Projects\MYSOLUTION\MYPROJECT\MYPROJECT.csproj" Targets="Clean;Rebuild" />
<!-- Delete old assembly file-->
<Exec Command="del /F /Q $(AssemblyPath)*.*" />
<!-- Copy built assemblies to Application_Assemblies folder -->
<Copy
SourceFiles="$(WorkingDirectory)Projects\MYSOLUTION\MYPROJECT\bin\Debug\MYPROJECT.dll" DestinationFolder="$(WorkingDirectory)WebSites\MYSOLUTION\Application_Assemblies" SkipUnchangedFiles="true" />
Notice that I’ve used the <Exec /> Task rather than the built in <Delete /> Task, because the assembly to delete is read only which causes the <Delete /> task to fail.
I hope that these issues will disappear when Beta 2 of Whidbey is released later this year, as the impact of the issues in building the website through MSBuild means you have to manage your build script (and in particular your project references) manually, which can cause build failures.