MSDN Magazine - March 2008 - (Page 72)

Figure 4 Targeting SetupVirtualDirectory format *.Test.dll. As long as developers follow this convention, the build scripts don’t need to change for additional test projects. This script, named GuestBook.msbuild, is located in the Build directory, and I placed a batch file, Build.bat, in the Source directory. Developers will be living out of the Source directory, so having a batch file there will make it easy for them to execute the build script: call “%ProgramFiles%\Microsoft Visual Studio 8\VC\vcvarsall.bat” msbuild ..\Build\GuestBook.msbuild /t:Build SET /P variable=”Hit Enter to exit.” your script as well (databases, IIS, registry entries, environment variables, and so on). The key is to spend the few minutes it takes to codify your development environment. Doing this will make setting up a new environment simple when you need to set up additional CI servers. When running the build script on the CI server, I may want to test in a more true-to-life environment. This is easily accomplished by executing an installer. The guestbook solution includes a Web Deployment Project: GuestBookSetup.vdproj. To build this project I need to call devenv.exe instead of MSBuild, since deployment projects are not currently supported by MSBuild: Build and Test At this point I’ve laid the groundwork for a basic build script to manage external dependencies, compile, and execute unit tests, like the following: The first target, SetupVirtualDirectory (see Figure 4), will map the Web Application Project directory in IIS as a virtual directory. This is the only external dependency for this project. Also, SetupVirtualDirectory allows a developer to avoid the time-consuming step of deploying the Web application. Later, when I am executing this script on the CI server, I will actually perform a full install. The compile target is simple as well. It scans the Source directory for any C# projects and compiles them: I will need to execute the install silently, as this will be a fully automated build. This is something that is best known up front when writing an installer. It can be troublesome to try and add this capability after the installer has been written. In the MSBuild script I need a target to install and uninstall, like so: These targets use the Exec task to execute the MSI file with the application msiexec.exe, found in PATH. The switch /i is for install, /x is for uninstall, and /q is for quiet. This installer package requires no user input; the default settings are acceptable for testFigure 5 Running Unit Tests with MbUnit and MSBuild There are two C# projects—the app project and the test project: C:\Projects\GuestBook\Trunk\Source\ Unit Test\GuestBook.Test\GuestBook.Test.csproj C:\Projects\GuestBook\Trunk\Source\Production\ GuestBook\GuestBook.csproj Note that while this approach allows for new projects to be added without requiring a change to the build script, you do lose the ability to control the order in which your projects will be built. This creates a significant problem if you have dependencies between projects. In the case where you need to control the build order, explicitly list your projects in the ItemGroup. To run the unit tests, I will use MbUnit via its associated MSBuild task (see Figure 5). It takes a list of assemblies as an argument and executes all the tests in each. The script is set to scan the Unit Test directory for each and every file in a bin directory matching the 72 msdnmagazine Continuous Integration

Table of Contents Feed for the Digital Edition of MSDN Magazine - March 2008

MSDN Magazine - March 2008 Contents Toolbox CLR Inside Out Data Points Advanced Basics Office Space Introducing ASP.NET MVC Loosen Up CI Server Performance Office Development Test Run Security Briefs Extreme ASP.NET Foundations .NET Matters {End Bracket}

MSDN Magazine - March 2008

For optimal viewing of this digital publication, please enable JavaScript and then refresh the page. If you would like to try to load the digital publication without using Flash Player detection, please click here.