Developer.Blog();

It’s clear that Microsoft wants all of us to use TFS. The reality is, that won’t happen. Using a build server other than TFS adds some complications that just simply shouldn’t exist. I spent over three hours today working through the various issues of my first MVC4 project. Allow me to regurgitate the issues and fixes so that you may be better prepared and have fewer issues.

Step 1: Install the .Net 4.5 Runtimes. This is easy via a download from the Microsoft web site.

Step 2: Install the Team City upgrade that supports .Net 4.5. Again, easy through a link on the JetBrains web site.

Step 3: Create Team City project. Check.

Step 4: Click Run. Uhoh. Lots of errors.

The first one to tackle is a missing reference to System.Web.Mvc. How can that not be found? I installed the .Net Framework. Well…it’s actually not part of the framework. I then tweeted, “First .Net 4.5 build fails on build server. Looks like some .Net assemblies are missing.”. Peter Ritchie replied with a link to a blog post from Marc Gravel. The comments in that post suggest to copy the files from your local install to the build server. I that, then reran the build. Still missing references to System.Web.Mvc.

I jumped up to the Asp.Net web site to grab the install, but group security policies prohibited the Web Platform Installer from running on the server. I did a web search for “download MVC4″ and found this link to get it. I downloaded that, installed it on the build server and reran the build. System.Web.Mvc was found. I got past that error, but now a new one saying that a build task was missing for the database project.

Ugh. Why, oh why, can’t Microsoft have a single download with everything you need for a non-TFS build server? More web searching yielded this post on what you need and links to download everything. OK, more grumbling about Microsoft not including everything needed. I get the files and following the instructions on the link. Except that I can’t do step 5. The folder doesn’t exist. Let’s try it anyway. I run the build and the database errors are gone. But now there are new ones about missing the AutoMapper assembly.

The AutoMapper DLL is sitting in the bin folder on my local drive. It makes sense that the DLL is missing. The entre bin folder is ignored and not pushed to the Git server. What if there are other assemblies in that same folder that I need? So, I fire-up Visual Studio and do a Build -> Clean. Sure enough, there are a few assemblies that are still there then tweet a gripe about this. Paul Stack if I was using bindeployable assemblies. No, I’m not. IMO, it shouldn’t be my responsibility to do this, except with my own internal assemblies. If I NuGet a package (looking at you, AutoMapper), it should install into the bindeployable folder of the project.

I copy the assemblies from my local bin folder to the build server and rerun the build. And…it works. I finally have the build running on the build server. Total time over three hours to get this project running.

What’s the solution to all this? First, Microsoft should have a single download package that includes EVERYTHING needed to build a project on the build server. By this, I mean all the Microsoft assemblies, including MVC and database projects. Short of this, provide a SINGLE page that can be EASILY found that lists what you’ll need and links to download it.

Second, NuGet pacakges should get deployed to the bindeployable folder, not just the bin folder. This way, you can easily check them in to your version control system.

Static code analysis is a valuable tool to find many errors in your code. What is static code analysis? It’s a process to analyze the code or assemblies themselves rather than testing the application by running the code. Hence, the analysis is static. There are a couple of free tools that allow you to do static code analysis on .Net code. The first, FxCop analyzes the generated assemblies. It checks assemblies for correctness, library design, internationalization and localization, naming conventions, performance, and security issues. The second tool, StyleCop analyzes that actual source code. I’ll discuss it in a future post.

To get FxCop, you need to download and install the Windows SDK. Once that is done, run %ProgramFiles%\Microsoft SDKs\Windows\v7.1\Bin\FXCop\FxCopSetup.exe to install FxCop. You should do this on both your development machine and your build server. You’ll now have an FxCop entry on your start menu. Use it to launch the FxCop GUI.

I won’t go into how to use FxCop or interpret the results. This is will docmented in the FxCop help file and also here and here. You should create a new FxCop project for each Visual Studio solution that you analyze. You should save the FxCop project file with your solution and check it into version control. We put it in the same folder as the Visual Studio solution file.

We also set a few FxCop project options. To so this, right-click on the FxCop project and select Properties.

On the General page, you should enter the name of your project. This keeps things need and tidy. You may be tempted to check Apply style sheet when saving report. However, when you check this option, it will cause TeamCity to not include the analysis report in its HTML output. You can still get to the report, but it will be presented as raw XML.

The next settings we made are on the Spelling & Analysis page. We checked all the options.

Next you need to select the Targets to add. These are the assemblies generated when you build the solution. There is no need to include Microsoft and third-party assemblies. That will generate too much clutter in your results. Just select the assemblies generated as part of your code. Remember that the location of the assemblies may be different on the build server than on your development machine. For example, our build process  does not generate a Debug version, only Release. If you create MVC applications, you can point to the assemblies in the Bin folder. Because this location is saved with the FxCop project, you need to save a location that’s avalailable on the build server. The location saved is relative to the FxCop project file.

When you have everything working, make sure to save your FxCop project file and then check it into your version control system. Now it’s time to setup Team City to run the analysis.

You probably don’t want to run code analysis with every build, especially if you are doing Continuous Integration (CI) with every checkin. Static code analysis is a good candidate for your nightly build. It should also run only after the build successfully completes and unit tests pass.

Modify the TeamCity project and add a build step. Here’s how we have things setup.

The Installation root is where FxCop was installed on the build server. We are using the FxCop project file because this makes it easier to manage. The developer is responsible for their Visual Studio project and by referencing the FxCop project, we don’t have to modify the TeamCity project when assemblies are added.

Now when you run the build in TeamCity, you’ll get FxCop results as part of the build. The TeamCity home page reports the results. When you drill-down into the Code Analysis, you’ll find a complete list of issues that were found.

And there you have it. The basics of running FxCop as part of your TeamCity CI process.

Our book, Continuous Integration in .NET is generating lots of interest around the Interwebs. If you’re wondering about this book, you can get some free excerpts. The latest is a look at using TeamCity for your CI server. Check them all out, then go buy the book.

Chapter 1: Grokking Continuous Integration
Green Paper: Continuous Integration in .NET
dotNetSlackers.com: Continuous Integration with TeamCity