Mike Swanson

October, 2004

  • Mike Swanson's Blog

    Glass Windows Wallpaper and 3D Animated Desktop


    Here's a thumbnail from some very nice wallpaper images from DivineError. He has a 1600 x 1200 version, a 1280 x 800 widescreen version and a non-glass version. He's created a lot of other great images too, if you spend the time to look through his collection.

    Speaking of desktops and wallpaper, if you want to completely amaze your associates and suck all the power out of your laptop or desktop computer, try this very cool 3D animated desktop called Desktop Dreamscapes. It's a 3D animated desktop...not screen saver, and notice that it's been around since 2002. Amazing stuff.

    And before I finish, let me plug my own Macro Wallpaper and Macro Wallpaper 2 posts.

  • Mike Swanson's Blog

    Replicating OnSuccess and OnFailure in MSBuild


    As you may have read in an earlier post, I'm currently helping a customer migrate their project from Visual Studio .NET 2003 to Visual Studio 2005. Our current build script uses NAnt, and we're in the process of converting it to MSBuild. Since we're big fans of continuous integration, and we depend on our Ambient Orb for at-a-glance build status, we have a need to replicate the behavior of NAnt's OnSuccess and OnFailure properties.

    I wasn't able to find similar MSBuild functionality by browsing through the limited information I have (or can find on the internet), so I sent an e-mail to our internal team, and Alex Kipman was kind enough to suggest this solution:

    <Project DefaultTargets="A;OnSuccess" >

          <Target Name="A" DependsOnTargets="B;C;D" >

                <OnError Targets="OnFailure" />



          <Target Name="OnFailure" >

                <DoSomething />



          <Target Name="OnSuccess" >

                <DoSomething />




    Although this technique isn't as intuitive as the NAnt solution, it does work.

  • Mike Swanson's Blog

    New William Shatner Album: Has Been


    Hilarious! Yes...you read that right...William Shatner has an album. Why didn't I know about this? I think William Shatner is a genius. He continually reinvents himself, and he isn't afraid to make fun of his career. I was at Best Buy today, and obviously, I didn't know about this, or I would have bought the album. If you're curious, listen to the interview at his site. Did anyone pick this up yet?

    Update: MSN Music's Sound Check currently has a streaming version of the entire CD available for preview.

  • Mike Swanson's Blog

    My Candy Cigarette Addiction


    Anyone else love candy cigarettes...err...I'm sorry...just plain Candy (they don't like to use the term cigarette next to the word candy anymore). A former Microsoftie and friend named Bill (who now works for Sagestone Consulting) was thoughtful enough to bring me a full box from a recent trip he took. I'm sure I was beaming when he walked in the door with a display box in his hands...how embarrassing.

    I've received a lot of grief from people over the years about eating these things. Comments seem to center around chalk. As in, "yuck...they taste like chalk!" To which I routinely reply, "how do you know what chalk tastes like?" That argument never works, though, and I've found it difficult to get people to try them.

    However, either times have changed, my persuasiveness has improved, or the people I now work around are just plain cool. More people than I thought remember these fondly, and almost everyone wants to eat a pack. I remind them to be careful of the lit end, clearly marked by the red food col...err...ember at one tip. "By the way," asked Dr. Steppe earlier today, "have you ever wondered why we chew them from the un-lit end?" Good question.

    If you haven't yet kicked the habit, you can save up all your money and buy your own box of 24 for $4.49. Update: Andy points out a $0.50 cheaper source.

    Anyone else remember these? How about other candies that you loved as a kid? Any of you have special "coding candy" to help you write VB.NET and C# code late into the early morning hours?

  • Mike Swanson's Blog

    CruiseControl.NET and MSBuild


    I'm currently helping the Robertson Research Institute convert their large C# Visual Studio .NET 2003 applications to Visual Studio 2005 ("Whidbey") Beta 1. For the past year-and-a-half, we've used CruiseControl.NET (CC.NET), NAnt, NUnit, and FxCop to automate our build, unit testing, and static code analysis. Now that we're running under the .NET Framework 2.0, we'd like to leverage the MSBuild tool in our processes (unfortunately, the most recent version of NAnt doesn't understand the new file formats). Fortunately, the new formats can be directly consumed by MSBuild.

    So, I spent some time today trying to figure out how to get the latest versions of these tools to work together. Although I wasn't able to achieve a perfect solution, I did find a configuration that is workable until CC.NET adds native MSBuild support. Here are some of the ideas I considered:

    Because I wanted a simple solution, I decided to try the commandLineBuilder. Additionally, since the CC.NET team is already planning MSBuild support, it should be an easy transition when the new feature finally arrives. So, the setup I'll describe uses NUnit 2.2, FxCop 1.30 for .NET 2.0, and the latest nightly build of CruiseControl.NET.

    NUnit 2.2

    Before you do anything else, you should modify your NUnit 2.2 configuration file to prefer the .NET Framework 2.0. You'll need to do this for CC.NET to successfully run your unit tests. Open the nunit-console.exe.config file and find the following section:

           <supportedRuntime version="v1.1.4322" />
           <supportedRuntime version="v2.0.40607" />
           <supportedRuntime version="v1.0.3705" />
           <requiredRuntime version="v1.0.3705" />

    Then, move the version 2.0.40607 element to the front of the list and save:

           <supportedRuntime version="v2.0.40607" />
           <supportedRuntime version="v1.1.4322" />
           <supportedRuntime version="v1.0.3705" />
           <requiredRuntime version="v1.0.3705" />

    As a side note, if you plan to use the NUnit 2.2 GUI for manual testing, you'll have to make the same change to the nunit-gui.exe.config file.

    MSBuild and FxCop

    MSBuild scripts can range from the very simple to the very complex. For this example, we'll stick with something easy. Whether you know it or not, the solution and project files that Visual Studio 2005 produces can be directly fed into MSBuild. So, for a solution called Bank.sln, I can build all of its projects by typing MSBuild Bank.sln. Although this works with solution files, they are not actually in the official MSBuild XML format. But, project files are. And the best part is that you can manually modify the project/MSBuild file and Visual Studio 2005 will respect your changes. Okay...I'm getting off-topic...let's get back on track...

    If you don't want to run FxCop analysis as part of your CC.NET build, you do not need to create your own build file. However, if you'd like to include FxCop analysis, you can create your own build file in the same directory as your solution file. For example, I created the following Bank.msbuild file:

    <Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
      <Target Name="Build">

        <!-- Clean, then rebuild entire solution -->
        <MSBuild Projects="Bank.sln" Targets="Clean;Rebuild" />   

        <!-- Run FxCop analysis -->
        <Exec Command="FxCopCmd.exe /project:C:\depot\Bank\Bank.FxCop /out:C:\depot\Bank\Bank.FxCop.xml" WorkingDirectory="C:\Program Files\Microsoft FxCop 1.30" />     


    This file has a single target called Build. The first thing it does is call MSBuild on the Bank.sln file. The Targets attribute says that we'd like to execute the Clean task first (which deletes all of the old build output), then execute the Rebuild task. I run Clean so that there are no old files from the last build left sitting in the output folders. It can be confusing if your build fails but the unit tests pass. This is usually because the old unit test assembly is still hanging around from a prior successful build. Using Clean eliminates that problem.

    Next, the Exec command executes FxCop. I have it execute against an FxCop project file, but you can call it directly against an assembly if that works better for you. I've directed the output to an xml file that will later be merged into the build and NUnit output so it can be reported by CC.NET.


    Now we need to tell CC.NET to call our MSBuild file (or, if you don't need to run FxCop, you can directly call the solution file). Although there are many sections in the ccnet.config file, these are the elements that we're interested in:

    <build type="commandLineBuilder">
        <buildArgs>Bank.msbuild /p:Configuration=Debug</buildArgs>


    Notice that instead of using a build type of NAnt, we've specified the commandLineBuilder. This allows us to call anything we'd like at the command line. The baseDirectory points to the directory containing the Bank.msbuild file that we created earlier. The buildArgs specifies the name of the build file and any other command-line options we'd like to send to MSBuild. If you don't plan to run FxCop, you can simply call MSBuild on the solution file by replacing the buildArgs with the following line:

        <buildArgs>Bank.sln /t:Clean;Rebuild /p:Configuration=Debug</buildArgs>

    Since our MSBuild script doesn't get the latest source from the source repository, you'll want to let CC.NET do it by setting autoGetSource to true in your sourcecontrol tag.


    To run the NUnit tests, use the nunit task by specifying the path to the NUnit console application, and list the assemblies that you'd like to test. Because we're using CC.NET's nunit task, we don't need to worry about merging the test output (like we might normally have to do if we were using NAnt).

        <!-- No file merging necessary if using CC.NET's NUnit task -->
    path>C:\Program Files\NUnit 2.2\bin\nunit-console.exe</path>

        <!-- Merge FxCop output -->


    Last, we do need to tell CC.NET to merge our FxCop output. This lets us see the FxCop detail on the CC.NET web site.


    Although this isn't a perfect solution, it's a great temporary solution that doesn't take a lot of effort. By using this configuration, you'll be able to use MSBuild, run your NUnit 2.2 tests, and leverage the latest version of FxCop all under the control of CruiseControl.NET. The only downside is that—because CC.NET doesn’t know how to capture useful build output from the commandLineBuilder—you won't see your build warnings and errors in the CC.NET e-mail or on the web site. Although this sounds like a show-stopper, you can use the original log link on the web site, and it is trivial to quickly find the last failure.

    If you're curious about MSBuild, you can find a three-part MSDN article here, here, and here. If you'd like to know more about CruiseControl.NET, continuous integration, and the Ambient Orb, check out my other article.

Page 3 of 4 (19 items) 1234