# The Obama Inauguration - Where Were You?

Sometimes you’re presented with a moment in time for which you want to remember where you were, what you were doing. I think the inauguration of Barack Obama, our 44th president, is one of those moments.

I watched the inauguration on the TV in the CheckFree Hillsboro lobby, drinking a red Amp, standing with my team and some of the other employees. It was a powerful event to watch and I look forward to the coming years to see how he does. I have a lot of hope.

Where were you for the inauguration?

# Moving From CruiseControl.NET to TeamCity

I admit to loving me some good ol’ CruiseControl.NET for continuous integration but there’s just something to be desired from the UI and ease-of-use/ease-of-administration standpoint. CI Factory brings it a step closer to what I’m looking for, but after doing some evaluation, we ended up trying out TeamCity.

It’s awesome.

It’s easy to set up, easy to administer, flexible, customizable… really, the experience thus far has been pretty great. At work we’re testing it out with the free Professional edition, but if it works out on this project, we’ll be getting the full Enterprise edition. I know that if I set up a continuous integration server for CR_Documentor it’ll definitely be TeamCity.

That said, there are some differences in how you have to do things in TeamCity than if you’re working in CruiseControl.NET. Here’s what I’ve found so far. (Note - I’m using MSBuild in my code snippets. If you’re using NAnt or something else, you get to translate.)

$(CCNetLabel) becomes $(BUILD_NUMBER). In CruiseControl.NET you access the current build number (e.g., “1.5.10.1234”) with the variable $(CCNetLabel). In TeamCity, it’s $(BUILD_NUMBER). Something we’ve done to make this easier is creating a variable $(BuildLabel) that we copy the appropriate value into at the beginning of the script. Doing that allows you to separate your build script from the build server proprietary variables. Builds are generally done with agents. In CruiseControl.NET, if you want to run a private build you drop to the command line and build it yourself. In TeamCity, you can ship your changes off to the server to run a personal build. There is a variable provided $(BUILD_IS_PERSONAL) that will equal “true” if the build is running for an individual rather than as part of the “official” process. You’ll want to update your build script to accommodate both personal builds via agent and via command line.

This sample shows some MSBuild logic that sets a $(BuildLabel) property based on whether a build is personal or not. It also sets a $(CCNetLabel) property for backwards compatibility with scripts that might be using that.

<Project
InitialTargets="__EnvironmentSetup"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="__EnvironmentSetup">
<CreateProperty Condition="'$(BUILD_NUMBER)' == ''" Value="true"> <Output TaskParameter="Value" PropertyName="BUILD_IS_PERSONAL"/> </CreateProperty> <CreateProperty Condition="'$(BUILD_IS_PERSONAL)' == 'true'" Value="0.0.0.0">
</CreateProperty>
<CreateProperty Condition="'$(BUILD_IS_PERSONAL)' != 'true'" Value="$(BUILD_NUMBER)">
</CreateProperty>
<CreateProperty Value="$(BuildLabel)"> <Output TaskParameter="Value" PropertyName="CCNetLabel"/> </CreateProperty> </Target> </Project>  Use the TeamCity test runner for better integration. While you can still use a straight call to, say, NUnit-Console.exe, you get very rich interaction and reporting in the TeamCity UI if you use the TeamCity version of the runner for your tests. You’ll want your script to “sniff” and see if it’s running on a developer box or in a TeamCity environment and use the appropriate runner. This sample shows some MSBuild logic that builds an appropriate test runner command line for running NUnit 2.4.8 tests based on the environment. It assumes you have a list of test assemblies in a @(TestAsemblies) collection. <PropertyGroup Condition="'$(BuildLabel)'!='0.0.0.0'">
<TestCommandLineExe>$(teamcity_dotnet_nunitlauncher)</TestCommandLineExe> <TestCommandLineArgs>v2.0 x86 NUnit-2.4.8 @(TestAssemblies->'%(FullPath)', ' ')</TestCommandLineArgs> </PropertyGroup> <PropertyGroup Condition="'$(BuildLabel)'=='0.0.0.0'">
<TestCommandLineExe>path\to\NUnit-Console.exe</TestCommandLineExe>
<TestCommandLineArgs>@(TestAssemblies->'%(FullPath)', ' ') /xml:TestResults.xml</TestCommandLineArgs>
</PropertyGroup>


There are two ways to integrate FxCop into the build. The first is to use the built-in FxCop build runner. This will run just FxCop though, and as a separate step. If you’re OK with not running FxCop as part of your CI build, that’s the easiest way to go. If you want to run the FxCop command line, though, and get the report into the UI, you need to use a “service message”

• a message to Console.Out in a special format - to tell TeamCity where to get the report.

This sample shows what a service message to get FxCop command line output into TeamCity might look like.

<Message
Text="##teamcity[importData id='FxCop' file='fxcop-report.xml']"
Condition="'$(BuildLabel)'!='0.0.0.0'" />  NCover support is manual. The stock TeamCity code coverage support is for EMMA. If you want NCover reporting to show up in the UI, there’s a little work to do. This blog entry shows a great in-depth how-to, but the simple version boils down to: 1. Set up your HTML coverage report (e.g., the output from NCoverExplorer) to be published as a build artifact (along with your binary/compiled output). 2. Update your TeamCity main-config.xml file to include the report. You’ll most likely want to comment out the other code coverage related report tabs since you probably won’t be using them. For example, if you publish the report as “CoverageReport.html” then your main-config.xml file might have a line in it like: <report-tab title="Code Coverage" basePath="" startPage="CoverageReport.html" />  You will probably also want to see a trend report of code coverage over time. To do that, you need to have your build script publish the data to TeamCity (again using “service messages”) and you need to add the custom graph to the build dashboard. The MSBuild logic to publish the code coverage overall percentage to TeamCity looks like this. Note that in this example, it’s assumed that the output from NCoverExplorer has been written to “CoverageReport.xml” • adjust your paths as needed. <XmlRead XPath="//coverageReport/project/@coverage" XmlFileName="CoverageReport.xml" Condition="Exists('CoverageReport.xml')"> <Output TaskParameter="Value" PropertyName="CoveragePercent"/> </XmlRead> <Message Text="##teamcity[buildStatisticValue key='coveragePercent' value='$(CoveragePercent)']" Condition="'$(BuildLabel)'!='0.0.0.0'" />  In your main-config.xml file, you then need to add the custom graph so it shows up in the build statistics page: <graph title="Code Coverage"> <valueType key="coveragePercent" title="% Coverage" /> </graph>  The important bit there is that the value of “key” in the “service message” matches the value of “key” in the graph description. Users set up their own notifications. In CruiseControl.NET, the build configuration specifies who gets alerted and to which build events. I hate that. I get all sorts of notifications I want because I happen to be on a mailing alias that was added administratively to the notification list. I can’t get out of it. In TeamCity, I get to configure my personal preferences for my notifications. This can be weird for some users who wonder why they’re not getting notified anymore • they need to do the work themselves to subscribe. Users need to tie their TeamCity accounts to version control system accounts. There’s a lot of functionality in TeamCity that allows you to deal with “changes you made.” The way TeamCity figures this out is by each user providing a mapping of their TeamCity account to their username on the various version control systems they use. The “my changes” features won’t work for people that don’t set this up. (There is no analogous behavior in CruiseControl.NET.) Builds aren’t done from working copies. In CruiseControl.NET when the build server checks out the source, the build is actually run from a live Subversion working copy. In TeamCity, the code still gets checked out from Subversion, but none of the Subversion admin directories (.svn) are there - it’s not a working copy, it’s an exported checkout. This is important if your build script tries to do anything with the version control system like inspect the location from which the current working copy was checked out. You can mitigate this in TeamCity by providing a custom environment variable (e.g., $(BUILD_VCS_ROOT)`) that contains this information. It won’t be dynamic, but it’s the best you can do.

You can’t serialize builds. In CruiseControl.NET there’s a notion of a “build queue” such that if one build is running, it can “lock” a semaphore and other builds that require that semaphore won’t run until it’s free. That sort of thing is helpful if your build script dynamically registers third-party assemblies in the GAC for the duration of the build, for example. There is no such serialization mechanism in TeamCity.

You can get notified of build events via Google Talk. Technically the “Jabber” protocol, but Google Talk nonetheless. You’ll need to get your build server a Google account, but once you do, people can add that service account to their friends list and configure Google Talk notifications. They tell you how to do this in the TeamCity docs but they don’t tell you what to do if port 5222 (the Jabber port) is blocked off at your firewall - switch to port 80. Here’s what works for me:

• Port: 80
• Server user: our-service-account@gmail.com

All in all, TeamCity is the advance in the build server that I was hoping would come along for CC.NET. It’s well worth the time to check out.

# Typemock Isolator Has a New VB.NET Friendly API

Typemock Isolator 5.2 is out, and they’ve updated their mocking API to be more Visual Basic friendly. If you’re quick about it, you may even be able to procure yourself a free personal license.

Actually, they already have a pretty good blurb on it, so why don’t I just let them say it?

Programming Visual Basic applications?

Typemock have released a new version of their unit testing tool, Typemock Isolator 5.2. This version includes a new friendly VB.NETAPI which makes Isolator the best Isolation tool for unit testing A Visual Basic (VB) .NET application.

Isolator now allows unit testing in VB or C# for many “hard to test” technologies such as SharePoint, ASP.NET MVC, partial support for Silverlight, WPF, LINQ, WF, Entity Framework, WCF unit testing and more.

Note that the first 25 bloggers who blog this text in their blog and tell us about it, will get a Free Full Isolator license (worth \$139). If you post this in a VB.NET dedicated blog, you’ll get a license automatically (even if more than 25 submit) during the first week of this announcement.

I already have a license, so I won’t be submitting my entry, but if you don’t have one, now’s a great opportunity to get Typemock Isolator for free.

# Running Chrome on 64-bit Windows 7

I saw this over on Gizmodo (who saw it on BlogsDNA) and thought it’d be worth passing along. I haven’t gotten a chance to run Windows 7 myself, but for those who have and want to get Google Chrome running on the 64-bit version, you need to add the “–in-process-plugins” parameter to the chrome.exe command line.

# Book Review: Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB

Professional ASP.NET 3.5 Security, Membership, and Role Management with C# and VB is, other than a heck of a long title, probably one of the most useful books I’ve read through in recent memory.

You know when you’re working on an in-depth item related to, say, ASP.NET membership and you search the web only to find 100 tiny articles that almost cover what you’re looking for? You know how you wish someone would make a book that would just aggregate all of that knowledge and maybe take it just a little deeper?

This is that book.

• Chapter 1: Introducing IIS 7.0
• Chapter 2: IIS 7.0 and ASP.NET Integrated Mode
• Chapter 3: HTTP Request Processing in IIS 7.0 Integrated Model
• Chapter 4: A Matter of Trust
• Chapter 5: Configuration System Security
• Chapter 6: Forms Authentication
• Chapter 7: Integrating ASP.NET Security with Classic ASP
• Chapter 8: Session State
• Chapter 9: Security for Pages and Compilation
• Chapter 10: The Provider Model
• Chapter 11: Membership
• Chapter 12: SqlMembershipProvider
• Chapter 13: ActiveDirectoryMembershipProvider
• Chapter 14: Role Manager
• Chapter 15: SqlRoleProvider
• Chapter 16: AuthorizationStoreRoleProvider
• Chapter 17: Membership and Role Management in ASP.NET AJAX 3.5
• Chapter 18: Best Practices for Securing ASP.NET Web Applications

The introductory chapters on IIS 7 were particularly interesting to me, since I still maintain a lot of legacy code on IIS 6 and haven’t had the opportunity to get in-depth with IIS 7 quite yet. These really gave a great overview not only of the general request process for IIS 7, but also differences between IIS 6 and IIS 7 with a focus on places where security-related events happen (e.g., where a request gets authorized, when the thread principal gets set, how these things get set in different scenarios).

Chapter 4 had a great discussion on the different ASP.NET trust levels that your application can run under and what each means. It also explained how the permissions for your application get determined and how to customize the permissions in your application to give it only what it needs. Code access security is such a tricky thing, it was nice to see this laid out in a clear fashion.

Chapter 5 talked about the way configuration (web.config) gets read and what permissions you need in order to access it. It also discussed ways to encrypt the sensitive sections of configuration (settings that might contain passwords, for example) and ways you can create your own encrypted settings provider - even allowing the settings to be read from a location other than the config file.

Chapter 6 on forms authentication started out like every other ASP.NET book with a forms auth discussion, but this chapter actually got into details like how secure encrypted forms auth tickets are and ways to influence the forms auth process that you might not have originally considered.

Chapter 7 might also have been called “How to get ASP.NET and classic ASP to coexist in IIS 7.” While the focus on it is getting the ASP.NET authentication mechanisms to work with classic ASP (using IIS 7), the discussion went a bit deeper than that, even talking about topics like passing data between ASP and ASP.NET.

Chapter 8 is basically everything you ever wanted to know about session state but were afraid to ask. It’s not just what session state is and how it works, it goes into what exactly is stored in a SQL session database, how that data gets generated, how to secure it, and how to stop session-related DoS attacks.

Chapter 9 was a short chapter that talked about a few odds and ends that didn’t get covered elsewhere. This chapter was the one that felt a little disorganized and mishmash, but it was still useful information. Topics here included request validation, viewstate protection, the permissions needed for page compilation, and securing your site map.

Chapters 10 - 16 were about the role and membership providers. The overall system gets introduced in a chapter, then each out-of-the-box provider gets explained in super detail. For example, the SqlMembershipProvider chapter goes so far as to explain how the schema for the membership database gets versioned. Chapter 17 ties the role and membership stuff into ASP.NET AJAX so you can see how to work with it all from the client side.

Chapter 18, though, is where you’ll want to flip right to. This is where it all comes together - all the stuff you’ll have learned from the previous chapters, put together in a near-checklist form, so you can take a step back from the application you’re working on, look through this, and ask yourself, “Am I doing this in a secure fashion?” Common gotchas and attacks are discussed here as well as ways to protect yourself.

It’s definitely not for folks new to ASP.NET - if you haven’t written an ASP.NET app before or you’re just starting out, this isn’t for you. This book gives you in-depth information that, in some cases, you’d only otherwise get by using .NET Reflector to delve into the actual .NET assemblies and follow the code. It’s heavy, detailed information. For mid-level to experienced ASP.NET developers, you definitely need to pick this up.

In all, this is one of those books I’m really glad to have on my shelf, right alongside Professional ASP.NET 3.5 in C# and VB.