Queue huge sigh of relief… ahhhhhhh. I’m amazed at how quickly they turned that around. It’s interesting to reflect on how little care and maintenance this blog has needed in more than eight years. I guess I should count myself as lucky!

We thoroughly enjoyed ourselves! Many thanks to Leah, Matt and Bernie for their hospitality, and to Leann, Keilani and Kalona for being wonderful travel guides!

Here’s a list of ingredients:

1. A fresh TeamCity server running on Windows.
2. Visual Studio 2010 installed on the build server (with the MSBuild 4.0 bits).
3. The MSBuild Extension pack.
4. The MSBuild Community Tasks.

I’m going to assume you already know how to set up your project in TeamCity and check out the sources from the version control software of your choosing.

The first build step I have is a little orthogonal to the ultimate deployment process, but I will include it because ultimately I wanted the Windows app and the ClickOnce deployment to all share the same version number that can be tied back to the TeamCity build. One thing to keep in mind is to call MSBuild in TeamCity with command line parameters of: /p:Configuration=Debug (if you are doing a debug build). This way I can have the compilation configuration type stamped in the binary’s metadata.
Here is a sample MSBuild file called SetVersion.proj that I use:

<Project DefaultTargets="SetVersion" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <PropertyGroup>
    <Version>$(BUILD_NUMBER)</Version>
  </PropertyGroup>
  <Import Project="$(MSBuildExtensionsPath)\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks"/>
  <Target Name="SetVersion">
    <ItemGroup>
      <AssemblyInfoFilesFirst Include="$(MSBuildProjectDirectory)\FIRST_PROJECT\Properties\AssemblyInfo.cs"/>
      <AssemblyInfoFilesSecond Include="$(MSBuildProjectDirectory)\SECOND_PROJECT\Properties\AssemblyInfo.cs"/>
    </ItemGroup>
    <AssemblyInfo AssemblyInfoFiles="@(AssemblyInfoFilesFirst)"
                  AssemblyVersion="$(Version)"
                  AssemblyFileVersion="$(Version)"
                  AssemblyConfiguration="$(Configuration)"
                  AssemblyCopyright="© 2011 YOUR COMPANY. All rights reserved."
                  AssemblyProduct="First Project Name - $(Configuration)"/>
    <AssemblyInfo AssemblyInfoFiles="@(AssemblyInfoFilesSecond)"
                  AssemblyVersion="$(Version)"
                  AssemblyFileVersion="$(Version)"
                  AssemblyConfiguration="$(Configuration)"
                  AssemblyCopyright="© 2011 YOUR COMPANY. All rights reserved."
                  AssemblyProduct="Second Project - $(Configuration)"/>
  </Target>
</Project>

Note the use of the Extension Pack’s AssemblyInfo task which enabled me to set values in the AssemblyInfo.cs files prior to compilation.

Next, I needed to clean and build the sources and call the Publish target in the Winforms project. To do this, I used another MSBuild build step that targets a file called Publish.proj, listed below:

<Project DefaultTargets="DoPublish" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
  <Import Project="$(MSBuildExtensionsPath)\MSBuildCommunityTasks\MSBuild.Community.Tasks.Targets"/>
  <PropertyGroup>
    <Version>$(BUILD_NUMBER)</Version>
    <ClickOnceBuildDirectory>$(MSBuildProjectDirectory)\PROJECT1\bin\$(Configuration)\app.publish</ClickOnceBuildDirectory>
    <ClickOnceInstallDirectory>$(MSBuildProjectDirectory)\Publish</ClickOnceInstallDirectory>
    <ClickOnceHtmFileLocation>$(MSBuildProjectDirectory)\Build\publish.htm</ClickOnceHtmFileLocation>
    <ClickOnceFinalLocation>$(env_PublishUrl)</ClickOnceFinalLocation>
  </PropertyGroup>
  <Target Name="DoPublish">
    <RemoveDir Directories="$(ClickOnceInstallDirectory)" ContinueOnError="true" />
    <MSBuild Projects="MY SOLUTION FILE.sln" Targets="Clean;Build" Properties="ApplicationVersion=$(Version);Configuration=$(Configuration)"/>
    <MSBuild Projects="PROJECT1\CLICKONCE PROJECT.csproj" Targets="Publish" Properties="ApplicationVersion=$(Version);Configuration=$(Configuration);InstallUrl=$(ClickOnceFinalLocation);PublishUrl=$(ClickOnceFinalLocation)" />
    <MakeDir Directories="$(ClickOnceInstallDirectory)"/>
    <Copy SourceFiles="$(ClickOnceHtmFileLocation)" DestinationFiles="$(ClickOnceInstallDirectory)\publish.htm"/>
    <Exec Command="xcopy /E $(ClickOnceBuildDirectory) $(ClickOnceInstallDirectory)" />
    <FileUpdate Files="$(ClickOnceInstallDirectory)\publish.htm"
                IgnoreCase="true"
                Multiline="true"
                Singleline="false"
                Regex="{VERSION}"
                ReplacementText="$(Version)" />
  </Target>
</Project>

In order to get this to work, I needed to save a copy of the publish.htm file because this is not generated as part of the Publish target. In fact, it can only be generated when clicking Publish within the Visual Studio IDE. This is not acceptable for an automated build: bad Microsoft! No cookie for you! During the build, I needed to edit the publish.htm file so that I could tamper with it’s version number. I stored a copy of this file in my source tree in a Build folder. Note also the $(env_PublishUrl) variable. This is coming from the build properties in TeamCity. The value is the full UNC location to the ultimate resting place of the ClickOnce deployment. MSBuild needs this because when it generates the ClickOnce manifest, it uses the fully qualified location (FTP/HTTP or file) so that all clients can refer to that location for future for updates. Basically, MSBuild file does the following actions in order:

1. Remove the place where it is going to assemble the ClickOnce package (in case an prior artifacts exist).
2. Do a Clean and Build on the entire solution to compile the the source code into binaries.
3. Call the Publish target within the WinForms project and set the InstallUrl and PublishUrl locations to be the final package location.
4. Create the local folder where it’s going to assemble the package.
5. Copy the publish.htm file from the source archive to the package location.
6. Use xcopy to copy the output of the Publish target that ends up in the bin\Debug\app.publish folder.
7. Use the FileUpdate task to put our version number in the right spots in the publish.htm file.

BIG HAIRY CAVEAT: To make this work, I had to remove the following PropertyGroup properties from the WinForm’s .csproj file:

• MinimumRequiredVersion
• PublishUrl
• ApplicationRevision
• ApplicationVersion

Finally, I needed to move the resultant build package out onto a network share for consumption by clients. My build machine was not a member of the AD domain, so I had to manually map and delete network drives. Fortunately, the Command Line build step’s Custom Script mode handled this wonderfully. Think of it as a way to write a batch file on the fly using environment variables set up during the build.

NET USE P: "%env.PublishShare%" /USER:domain\username **password**
ROBOCOPY "%system.teamcity.build.workingDir%\Publish" "P:%env.PublishFolder%" /MIR
NET USE P: /DELETE

Note how I referenced the build’s working directory to find the published package, and two different Environment Variables that were set as part of the build configuration. This allowed me to target different network shares and folder structures without changing the script or any other build artifacts.

This wasn’t a difficult solution to arrive at, but it did give me the opportunity to learn a lot about MSBuild and both the Extension Pack and the Community Tasks add-on packages. After trying to accomplish a similar task with Cruise Control.net and a WCF webservice project, and giving up; I have become a huge fan of TeamCity and it’s ease of use. It only took three or four hours to get a brand new Windows Server 2008 Standard x86 (a requirement for WCF packages with COM dependencies) virtual machine stood up with TeamCity installed and working. That includes all the Windows Updates!

Happy Automated Building!

This year we are going to attempt to start a new Christmas tradition: the Christmas blog post. As I write this, the snow is streaming down outside and the lovely Jakki is busy gluing things to other things for our entries in an Unfortunate Holiday Sweater contest. Without further ado, here’s what we did in 2010:

After much review of Facebook and Twitter, it appears that 2010 started off with head colds for everyone, and braces for Jakki’s teeth. The early part of the year contained much internet browsing and watching of TV. Such is life in the Inland Northwest in the first quarter.

After thawing out, March came along and brought a fabulous gig for the band I’m with: Fairmount Chase. St. Patrick’s Day tends to bring out our most loyal and hardcore fans. Fortunately, the more they drink, the better we sound.

As temperatures began to rise, camping became possible and we scooted up to Farragut State Park along Lake Pend Oreille to celebrate Jakki’s birthday. In attendance were our friends Chuck and Leann and some of her family. After raining on the way up, the weather cooperated until we left.

In July, Lake Sullivan in the extreme northeast corner of Washington became our camping destination. Bocephus (our Dodge truck) got a new canopy and was able to keep our gear dry despite rainy weather.

To celebrate our anniversary in August, we returned to Packwood, Mt. Rainier and Mount St. Helens; the site of our wedding five years prior. We found the tree we were married in front of in the Ohanapecosh camp ground (not surprising, since that tree is probably 700 years old).

The last part of the summer was punctuated with two quick gigs for the band, one outdoors at a neighborhood block party in North Spokane, and one at O’Doherty’s; a staple in Fairmount Chase’s venue menu.

In early fall, we took a trip over to Seattle to visit Grandma Flo, Bob & Linda, Jim & Phyllis and Kelsey, and take in a Seahawks game at Quest Field with our friends Chuck & Leann. The family visit was wonderful, but the performance of the Seahawks left a lot to be desired (they lost 41-7 to the NY Giants). We also managed to see some old friends: Charlotte, and His Holiness Gary (the padre who presided over our wedding), and Georgie & Roger and their son Brian.

During fall, after much excitement with broken garage door springs, Jakki and I managed to get two new garage doors installed on the house. This was fortunate, as the first snowfall of the season set an all-time record for the area in November. Which, of course, brought out the Snow Robots.

This year has been heavily dosed with visits with family and friends, completely lacking in stays in the hospital, and fueled with music and good cheer— and we couldn’t be happier. May the holiday season bring you and yours peace and happiness in the coming year!

-Much Love, Kelly & Jakki (and Tigger & Cleo)

Now I’ve only been diabetic for a few years now, but every day (or meal, or test) I am reminded of it’s impact on my life. Please help the fight to end diabetes by sponsoring this Microsoft programmer dude I admire.

Thanks!

Recently I finished Rework by the guys who started 37signals. I read it on my iPhone and Kindle for PC, which was an interesting but overall pleasant experience. Putting my phone down at night, and then opening up the PC app at work during lunch the next day and having it go right to the page I was on is amazingly awesome.

Anyway, reading it inspired me to build some sort of software thing in my spare time. So I have been putting some hours into an idea from a friend and coworker, Allen Monroe. He is a bottomless “idea-guy” resource, which is great and inspiring in it’s own way. We also had some of our internet offerings go viral in the same week. He created a parody of Google’s super bowl ad, and I submitted a story and some code to The DailyWTF.

It’s been fun, but it hasn’t moved me toward my personal 2010 goal of contributing something to a Open Source Software project. I’ve been reading a fair amount of code lately, trying to find something to contribute to. If anyone has any ideas, please post in the comments.

Recently at home we’ve been trying to focus on getting more exercise. We bought a nice NordicTrack elliptical and set it up in the basement. I’m finding that changing one’s lifelong habits is a difficult thing. Especially with so much TV to watch :)

With the weather oscillating tantalizingly between Spring and Winter, Jakki and I are very excited to do some camping this year, especially since we now have a big truck and can pack ridiculous amounts of Glamper paraphernalia. The next stop is Trailerville!

The band I’m in (I hesitate to say ‘my band’ since I did not form it), has been having a lot of fun, and with Spring coming on, we are looking forward to many opportunities to play. I’m also working on getting them set up with some kind of blog thing so we can communicate with our fans better.

So to wrap up this quarterly update (and to try to motivate myself to do a better job of posting regularly): please stay tuned and keep in touch; I will endeavor to do the same.

Unfortunately, Jakki had to work, and my parents had a dancing engagement, so I don’t have any photos of the gig to the post. I’m thinking that I might need to ask Santa for a video camera, so I can begin building up a video library of the band to put on youtube for potential venue owners to look at.

1. The first type of coder/gamer is a person who likes the result of the game. They like the feeling that comes along with winning, or completing a level. If you played a dungeon-type discovery game such as Diablo with this person, generally they would be the person to reach the end of a level first. And then probably complain that you are taking too long. They enjoy the completion more than the act of playing. In fact, to them, the idea of playing is just the sum of all the completed levels so far. These types shall be known as the Completors.

2. The second type of coder/gamer is a person who likes the exploration and interaction of the game. Winning or completing a level is a secondary or n^th-erary aspect of the game. These people will want to explorer every possible room in a dungeon, possibly returning to visited rooms just to check “if anything new has shown up”. Obviously, this drives the type 1s crazy, as these archetypes enjoy the act of playing more than completion. Personally, this is the group I tend to fall into. These types shall be known as the Wanderers.

So which is better? I don’t believe the question is nearly as cut and dried as that. From a business point of view, results matter, and it would seem that a gang of Completors would the best team to create a business-critical on-time and under-budget enterprise-level highly-available software solution. Let me pause for a moment here, to let my jargon buffer refill. I think that a good level of success can be had with a group of coders more toward the Completor end of the spectrum. But that comes with a price. Because Completors are so results-oriented, once they find a good solution or strategy to beat “the game”, they will just continue to apply it over and over. Why fix it if it ain’t broke?

The problem with the security of these repeatable results is that the world of software (and the world of games) marches on at a blistering pace. New technologies and methodologies spring up like dandelions in the summer. I personally spend a good deal of time just trying to keep up with a small amount of the New Stuff. Completors tend to shy away from personal growth and exploration because that’s their nature. Over a career, or many careers, this can lead to a certain amount of software stagnation.

Now let’s look at the Wanderers. You might think after that last paragraph, that you really want a team of Wanderers! Unfortunately, that group has some downsides as well: They tend to be the worst estimators ever. Some projects, because the game space is so large, will never actually reach completion. When faced with a very structured deadline or result, Wanderers may fail (for certain values of failure). Because the idea of exploration and self growth is very important, Wanderers tend to not have as much loyalty or “team spirit” as Completors.

So what’s the final answer? Just like in many things in life— I believe that moderation is key. A group that is a well-mixed solution of different levels of these elements will reap benefits greater than the sum of it’s parts. Wanderers will inspire and enlighten the Completors, The Completors will keep the Wanderers on the right track, possibly dragging them over the finish line with them. As a manager, or project leader, I think that understanding these two archetypes and using their strengths and weaknesses together can make for a most potent team. After all, who wants to play Diablo with a group solely consisting of Barbarians?