Contents tagged with MSBuild
-
Better Log Formatting for CruiseControl.NET and MSBuild
This is just a blog post to bump the topic on search engines to help people using MSBuild and CruiseControl.NET to get to the right place. I personally recommend to use the "Improved MSBuild Integration" logging option by Christian Rodemyer. If you follow the instructions on this page, you'll get it right. You may also have to change the dashboard stylesheet somewhat if you want to add or remove smileys or other GUI-related things depending on the results from unit testing etc, but the output in the CruiseControl dashboard is nice and clean.
-
[MSBuild][Tools] MSBuildShellExtension - Nifty Tool for Builders
This little project from CodePlex is quite useful for those of you who are responsible for the Build process, Team Build, CruiseControl.NET, NANT, etc. This is the project description from their website on CodePlex:
MSBuild shell extension gives you what you've always wanted: A way of cleaning, building and rebuilding your .net projects from the explorer without needing to open Visual Studio 2005 or the Visual Studio 2005 Command Prompt.
It looks like this:
and when you run it, it builds the project or solution in a command window and displays the error/warnings dialog similar to the one in VisualStudio. Nice!
-
[MsBuild] Writing and Debugging Custom Tasks
Writing a custom task for MSBuild is very simple, here's the bare minimum code you would need to get you going:
using System;
using System.Collections.Generic;
using System.Text;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
namespace IRM.Tasks
{
public class HelloTask : Task
{
private string name;
[Required]
public string Name
{
get { return name; }
set { name = value; }
}
public override bool Execute()
{
Log.LogMessage("Hello " + name);
return true;
}
}
}
The task will obviously print out the value of the "Name" property to the log.
To test it, create a test-project like a dummy console app and add this to the end of the .proj file:
<UsingTask TaskName="IRM.Tasks.HelloTask" AssemblyFile="C:\code\HelloTask\bin\Debug\IRM.Tasks.dll" />
<Target Name="AfterBuild">
<HelloTask Name="Johan" />
</Target>
If you unload the project from the Solution Explorer window you can Edit it directly in VS.
But if you want to debug the task and set breakpoints in it? It was described by Neil Enns of the MSBuild team quite some time ago. After you have created a test-project and added the custom task to the .proj file as described above, do this:
- Open your custom task project
- Go to Project > projectname Properties…
- Go to the Debug tab
- Change the start action to “Start external program” and put in the full path to MSBuild as the program. In my case the path is “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe”
- Change the “Command line arguments” to the full path to your test project
- Close the property window
Now just start debugging your custom task, MSBuild should start up and start to build your test-project and will stop at any breakpoints you set in your custom task code. Neat!
-
How to Use Msbuild.exe with CruiseControl.NET
I just updated my primer/tutorial/walkthrough on CruiseControl.NET with some information about how to use msbuild.exe instead of devenv.exe in your minimal cc.net configuration. One good reason to go with msbuild is that you don't need to install VS.NET on a dedicated build server, and you can also target unit tests, performance tests, code analysis etc. that you may have added using the Team Edition versions of VS.NET.
Please check it out and comment on it if you please.
-
Quickstart on CruiseControl.NET
I just wrote a page about how to set up CruiseControl.NET to compile and test a VS.NET web app solution in a few minutes. It's over at my Walkthroughs and Tutorials section.
-
How to Hook Up a VS.NET 2005 Solution With CruiseControl.NET in a Few Minutes
This is a short "primer" on how to get your CruiseControl.NET (CC.NET) Continuous Integration (CI) Server up and running with a very small configuration, and it will only take you about 5 minutes or so. I’m pretty new to CC.NET so I thought I would share some of the stuff I learned about it when setting it up. I've used it before, but that was some time ago and now I’m planning on using it for an upcoming project so I had to brush things off and see what had changed lately.
I’m listing some NAnt resources as well here, even though I’m not covering NAnt now (but probably will in a future update). If you want to read about NAnt and CC.NET, Joe Field got a great article on it, and I'm sure there are other CC articles out there.
Updates
Nov 25, 2006 - Added information about how to use msbuild.exe and a small sample configuration.
Why CruiseControl.NET?
So why would you like to use something like CruiseControl.NET? Say you have an ASP.NET Web application solution with a few class library projects and some NUnit tests, you keep track of it using VSS and you want to make the move to CI. Say you want it to check out, compile, test and report every time new code is checked in or by schedule every night (this is up to you and dead simple to change). If this is something you’d like to do, keep reading.
Note that this has nothing to do with the Unit Testing features of (some of the) VS.NET Team System Editions, but CC.NET is so flexible it’s possible to use that feature too, via the <msbuild> <task> for example, but that’s for another time. I've updated this page (at the end) with a sample configuration for compiling using msbuild, but not for running unit tests with it (yet)
If you know the basics and just want to get to the configuration file, jump to the section near the end called “CC.NET Configuration” where you got the XML I came up with. Good luck.
Tools and Products
I'm using these tools and products:
- Visual Studio.NET 2005 + Visual Source Safe
- CruiseControl.NET version 1.1.2527, tool for doing Continuous Integration
- NUnit version 2.3.6293 for .NET 2.0, tool and framework for unit testing your code
- NAnt + NAntContrib version 0.85, tool and framework for performing complex build tasks, similar to msbuild.exe. The Contrib
package contains extra stuff you want to use as a NAnt user (not used in this paper yet, but make sure it’s the same versions if you decide to install them now)
Resources
Some good reasources, where you can download the things I listed above:
- CruiseControl.NET– http://ccnet.thoughtworks.com/
- NUnit – http://www.nunit.org/
- NAnt – http://nant.sourceforge.net/ (not used in this paper yet)
- NAntContrib – http://nantcontrib.sourceforge.net/ (not used in this paper yet)
- Great (longer) tutorial on CC.NET by Joe Field - http://joefield.mysite4now.com/blogs/blog/articles/146.aspx
Ways of Building Your Code
Just a few words about different ways to build/compile your code. There are various ways to do this of course, but a few typical ones:
- Let CC.NET build it by using the devenv.exe program (this requires you to install VS.NET on the build server)
- Let CC.NET hand over the build process to msbuild.exe.
- Let CC.NET hand over the build process to NAnt, which in itself can use devenv.exe or msbuild.exe to build you code.
Using devenv.exe is a simple way of doing it, CC.NET got a <task> for it, you just point at your solution file, and I’m sure it will be enough for most people who just wants to get going. But, it won’t give you the precise control you might want to have.
This paper will cover the first one, using devenv.exe, and the second one using msbuild.exe, but it should be enough to get you started.
Download
This tutorial assumes that you already have VS.NET 2005 installed. So start off by downloading the other products listed above. There’s no need to install NAnt unless you want to use that as your build tool. The simplest configuration of CC.NET handles the build on its own, without even involving msbuild.exe, but I recommend that you look at, learn and consider using NAnt for more complex/complete build tasks. You find the links in the Resource section.
Installing
Installing these things is pretty straight forward and needs no help. A few words though... Most of these products are actually mimicking the beautiful way most Java tools are installed – unzip into a directory of your choice. But I recommend using the .msi installers, especially that of CC.NET as it installs a Windows Service as well and a few useful shortcuts to the CC.NET configuration file and the documentation.
The CC.NET .msi installer also creates a website (CC.NET Dashboard) on your IIS if you got that installed. For some reason it doesn’t create any shortcuts to it from the Start menu. I’ll talk about that later.
Speaking about documentation I have to say that the docs are great in most places. Thing is that the stuff you need to read are spread out in several places and I couldn’t find any decent CC.NET configuration that suited me. That’s why I’m writing this paper...
My Test Solution
So, we need something to test on, so I created this mini web app, which consists of 3 VS.NET projects:
- A web app (I used the Web Application Project template for this)
- A class library for a simple Database Access Layer project
- A class library for a few unit tests (using NUnit)
Make sure you install these things so that the solution file is sitting in a folder “above” these projects, like this:
Solution (JohansTestSystem)
Web Project - Johan.Web
DAL Project - Johan.DAL
Test Project - Johan.Test
This will make everything sort of easier for all tools to handle the code and the projects. Start by creating an empty Solution and add new Projects to it as you go. VS.NET will make sure everything gets created where it should. It doesn’t matter where on your disk you are creating these projects, because we will check them out to and build them in another directory.
Finally – add them to Visual Source Safe (or whatever source control system you are using). CC.NET got support for many source control systems.
CC.NET Configuration
Now, to the reason why you are reading this – let me show you an example of a pretty slim configuration to start with. You find the configuration file (ccnet.config) in the /server/ directory of where you installed CC.NET, or via the Start menu created by the CC.NET installation. My examples does not involve NAnt at all right now and will let CC.NET handle the build by calling the devenv.exe or msbuild.exe.
Devenv.exe Configuration Sample
To understand why this first configuration file looks it does, I'll give you some info about where I have installed things and such:
- VSS is installed in C:\Program Files\Microsoft Visual SourceSafe\
- My VSS database is installed in C:\VSS\
- I got a user called “Johan” in VSS
- The solution file is checked into the VSS-project $/JohansTestSystem.root
- I’m checking out and building the solution in the C:\CI\ directory, which means the solution will be checked out to C:\CI\JohansTestSystem\
- I want CC.NET to look for newly checked in files every 60 seconds
- I want CC.NET to use VS.NET devenv.exe to build my solution
- I got NUnit installed in C:\NUNIT\
- I want NUnit to test the application after the build
This is a small, if not the minimum, example of a configuration file for this job:
<cruisecontrol>
<project name="Johans Test System">
<sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
<executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
<project>$/JohansTestSystem.root</project>
<username>Johan</username>
<password></password>
<ssdir>c:\vss\</ssdir>
<workingDirectory>C:\CI\</workingDirectory>
<cleanCopy>true</cleanCopy>
</sourcecontrol>
<triggers>
<intervalTrigger seconds="60" />
</triggers>
<tasks>
<devenv>
<solutionfile>c:\CI\JohansTestSystem\JohansTestSystem.sln</solutionfile>
<configuration>Debug</configuration>
<buildtype>Build</buildtype>
<executable>C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\devenv.com</executable>
<buildTimeoutSeconds>60</buildTimeoutSeconds>
</devenv>
<nunit path="C:\nunit\bin\nunit-console.exe">
<assemblies>
<assembly>C:\CI\JohansTestSystem\Johan.Test\bin\Debug\Johan.Test.dll</assembly>
</assemblies>
</nunit>
</tasks>
<publishers>
<xmllogger />
</publishers>
</project>
</cruisecontrol>
You may want to consider not labeling the code after a build (applyLabel="false") and use another trigger instead of the <intervalTrigger>.
Msbuild.exe Sample Configuration
Now I'll show you how to change the configuration above to use msbuild.exe instead. One good reason do use this configuration is that VS.NET does not have to be installed on the build server. NOTE! If you're using the new Web Application Project template for a website project, you must copy the file Microsoft.WebApplication.targets to C:\Program Files\msbuild\microsoft\visualstudio\v8.0\webapplications\ directory, or the build will fail! The reasons for this is described in several places on the Net.
The circumstanses described earlier are still valid, except that we're using msbuild.exe instead of devenv.exe. So, change the ccnet.config file to look like this:
<cruisecontrol>
<project name="Johans Test System">
<sourcecontrol type="vss" autoGetSource="true" applyLabel="true">
<executable>C:\Program Files\Microsoft Visual SourceSafe\ss.exe</executable>
<project>$/JohansTestSystem.root</project>
<username>Johan</username>
<password></password>
<ssdir>c:\vss\</ssdir>
<workingDirectory>C:\CI\</workingDirectory>
<cleanCopy>true</cleanCopy>
</sourcecontrol>
<triggers>
<intervalTrigger seconds="60" />
</triggers>
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\MSBuild.exe</executable>
<workingDirectory>c:\CI\JohansTestSystem</workingDirectory>
<projectFile>JohansTestSystem.sln</projectFile>
<buildArgs>/noconsolelogger /p:Configuration=Debug /v:diag</buildArgs>
<targets>Build</targets>
<timeout>15</timeout>
<logger>ThoughtWorks.CruiseControl.MsBuild.XmlLogger,ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<nunit path="C:\nunit\bin\nunit-console.exe">
<assemblies>
<assembly>C:\CI\JohansTestSystem\Johan.Test\bin\Debug\Johan.Test.dll</assembly>
</assemblies>
</nunit>
</tasks>
<publishers>
<xmllogger />
</publishers>
</project>
</cruisecontrol>
The changes are in bold. The <msbuild> task and the values should be pretty straight forward and they are well described in the ccnet documentation for msbuild. Msbuild doesn't come with XML output so a few friendly people made an XML logger for it, which you need to download and put in project working directory (for me it's C:/CI/JohansTestSystem/) and also reference in the <msbuild> task section (as you can see above). Read about msbuild and the logger on this page.
Finally, you need to do a few touches to the Dashboard configuration, which is the file called dashboard.config in c:/<ccnet>/webdashboard/ directory. First, add the compile-msbuild.xsl to the <xslFileNames> section, so that you get a somewhat nicer looking style to the msbuild output:
<xslFileNames>
<xslFile>xsl\header.xsl</xslFile>
<xslFile>xsl\modifications.xsl</xslFile>
<xslFile>xsl\compile.xsl</xslFile>
<xslFile>xsl\unittests.xsl</xslFile>
<xslFile>xsl\MsTestSummary.xsl</xslFile>
<xslFile>xsl\compile-msbuild.xsl</xslFile>
<xslFile>xsl\fxcop-summary.xsl</xslFile>
<xslFile>xsl\NCoverSummary.xsl</xslFile>
<xslFile>xsl\SimianSummary.xsl</xslFile>
<xslFile>xsl\fitnesse.xsl</xslFile>
</xslFileNames>
You could remove the other files that you're not using, or just leave them there, it doesn't hurt. Then you would like to add the msbuild output to the dashboard menu. In the same configuration file, add a <xslReportBuildPlugin> section:
<xslReportBuildPlugin description="MSBuild Output" actionName="MSBuildOutputBuildPlugin" xslFileName="xsl\msbuild.xsl" />
Run
Now, start CC.NET by clicking on the CruiseControl.NET shortcut on the desktop or find it via the Start menu, or look for ccnet.exe in the /server/ directory where you installed CC.NET.
Even better might actually to be to open up a command prompt and run it from there, because you may get at few errors or warnings the first time and it’s easer to CTRL-C and look at them from there. Don’t bother starting the CC.NET Windows Service until you got a decent config that works well.
If all is well, CC.NET should do its job and go back to sleep mode again, waiting for the next time to trigger. You should have gotten loads of output in the console window and something like this in the end:
[Johans Test System:INFO] Integration complete: Success - 2006-11-11 18:45:23
If not, go back and look at your config file where some path might be wrong. The errors output from CC.NET isn’t the best...
The CC.NET Web Dashboard
If you want to look at the results from the last build, or force a new build, you can use the CC.NET Dashboard. Note that ccnet.exe must be running.
Open a browser and go to http://<your CI host>/ccnet/ and you should see the dashboard where the right hand side shows the projects described in your configuration file, in this case only one project. Click on your project name and then on the report for the latest build which will show you the files modified since last time (and by whom), and how the test run went.
On the left hand side you can click on a number of links to get detailed reports if you like. The NUnit Details report is a good one, and as you can see, CC.NET got support for a number of other tools; NAnt, FxCop, NCover and so on.
That’s it for now. This page will probably get updated with other sample configs where I use NAnt and other configurations with msbuild. As soon as I get a few minutes to write something...