There's a nice post over at Public Void about deploying the Enterprise Library. I think I'll be using this over the summer, so this'll come in handy.

Almost a month ago, I posted about updating our build process, and asked if anyone wanted to see more details. I got a few people asking for it, so I figured I'd provide some more details of how we did some of things we did.

First, let's review what I changed. I added a "Prod" target, which does the following things:

 Stops the CruiseControl.NET service (this prevents builds from interfering with our prod build)
 Cleans both the dev and test directories
 Gets the latest into the dev directories
 Builds in release mode
 Copies files into the test directories
 Zips up the builds so they can be copied up to the production servers
 Optionally, it labels VSS with a command line specified label.
 Starts the CruiseControl.NET service again.

I'll go through the details of each one, and what the nant task is that will accomplish it.

To stop (and start) the cruise control service, it's pretty simple. First, you need to know how to start and stop services from the command line (net stop [ServiceName] and net start [ServiceName]). The service name for cruise control is ccservice, so the nant task to stop it is:

<exec program="net" commandline="stop ccservice" failonerror="false" />

I set it up to not fail on errors because it's not a fatal error if the service doesn't stop. I only stop the service so that if check-ins occur during the production build, the automatic build process doesn't kick off, and potentially screw up the production build. Starting the service is just as simple - change "stop ccservice" to "start ccservice" and you're good to go.

Before we talk about cleaning the directories, I need to back up a second and talk properties in Nant. A property is pretty easy to define. Here's the format:

<property name="Project.UseVss" value="true" />

This sets Project.UseVss to true. I highlight this property because I use this property to determine if the directories should be cleaned. We use Visual Sourcesafe in our build server, but all of our developers use SourceOffSite to access the source control, because our dev box is in California, while half of the developers are in Michigan. Even the guys in CA use SOS, because of some of the issues with solution and project files under source control - if two people use different source control systems, it constantly asks you to check out the project files. Anyway, if a developer wants to run the nant build locally, they probably don't want to get latest, so each developer can maintain their own properties in a separate XML file. Add this line to your build file:

<include buildfile="Properties.xml" failonerror="false" />

This tells Nant to look for a file called Properties.xml, and each developer can override any properties (or add new ones). The nice thing is that Nant doesn't puke if that file isn't found, so there's no need to keep this file under source control - each developer maintains their own copy. It's a lot like an alternate config file defined in web.config.

So each developer would set the Project.UseVss property to false. This tells our build process that any source control operations should be ignored. It also means that we probably don't want to clean the dev folders. When a developer builds locally, they are most likely testing a change they made - overwriting those changes would be counterproductive. So here is how our cleaning task is set up:

<if propertytrue="Project.UseVss">
 <call target="Clean" />
 <call target="UpdateAll" />
</if>

This also handles getting latest, which I'll talk about more later. The first thing to notice is that it checks to see if Project.UseVss is true. If so, then it calls two tasks - Clean and UpdateAll.

The clean target is fairly straight forward, with one exception. You have set each file to have normal attributes (not read-only) before you can delete it, and since most of our files are read-only (since they are coming from VSS), we have to do that. That's pretty simple:

<attrib normal="true">
 <fileset basedir="${Project.Root}\MyFolder\">
  <includes name="**/*" />
 </fileset>
</attrib>

This sets every file in \MyFolder\ (and sub folders) to have normal file attributes. Notice another property in use - Project.Root defines where $/ folder in VSS is mapped to - that way, each developer can use whatever folder structure they want - for example, I use c:\sourcesafe\NCM\ for my root, but on our build server, it's just c:\sourcesafe\.

Deleting the files is pretty easy too:

<delete>
 <fileset basedir="${Project.Root}\MyFolder\">
  <includes name="**/*" />
 </fileset>
</delete>

This recursively deletes all files. When I did the web folders, I was more explicit about what files I deleted - I didn't want to delete all of the files, such as project files, so I specified the types explicitly:

<delete>
 <fileset basedir="${Project.WebRoot}\MySiteFolder\">
  <includes name="\**.cs" />
  <includes name="\**.aspx" />
  <includes name="\**.aspx.cs" />
  <includes name="\**.aspx.resx" />
  <includes name="\**.asax" />
  <includes name="\**.asax.cs" />
  <includes name="\**.asax.resx" />
  <includes name="\**.css" />
  <includes name="\**.js" />
  <includes name="\**.scc" />
  <includes name="\**.htm" />
  <includes name="\**.jpg" />
  <includes name="\**.gif" />
  <includes name="\**.xml" />
  <includes name="\**.txt" />
  <includes name="web.config" />
  <includes name="\**.ascx" />
  <includes name="\**.ascx.cs" />
  <includes name="\**.ascx" />
  <includes name="\**.ascx.resx" />
  <includes name="bin\*.dll" />
 </fileset>
</delete>

Here's another use of a property - Project.WebRoot. Since some developers prefer to set up their virtual folders manually, so it's still under the source root and others let VS.NET choose where (usually c:\inetpub\wwwroot\), I added this so each developer could define their own path, as well as having a different path on our build server. Using the \**.ext format recursively deletes any file that ends with .ext.

The cleaning process goes through every project and cleans all of the folders in dev, as well as cleaning all of the test folders, which is where we deploy our test builds (yes, I know, having our test build and dev build on the same machine isn't best practice, but it could just as easily be cleaning and deploying over mapped drives).

Now that we've cleaned our folders, it's time to get the latest version of the source so we can build. Here's a full target for updating part of our source:

<target name="UpdateShared">
 <if propertytrue="Project.UseVss">
  <if propertyexists="Project.BuildLabel">
   <vssget user="${Project.VssUid}" password="${Project.VssPwd}" version="${Project.BuildLabel}" localpath="${Project.Root}\MyFolder\" recursive="false" replace="true" writable="false" dbpath="${Project.VssRoot}\srcsafe.ini" path="$/MyFolder" />
  </if>
  <ifnot propertyexists="Project.BuildLabel">
   <vssget user="${Project.VssUid}" password="${Project.VssPwd}" localpath="${Project.Root}\MyFolder\" recursive="false" replace="true" writable="false" dbpath="${Project.VssRoot}\srcsafe.ini" path="$/MyFolder" />
  </ifnot>
 </if>
</target>

A few things to notice here. First, we only get latest if Project.UseVss is true. The next item is checking to see if Project.BuildLabel exists. If this is defined, we tell VSS that we don't want the latest version, but we want the version that was labeled with the value in Project.BuildLabel. This property isn't defined anywhere in our build file. If you want to get a label, on the command line you add -D Project.BuildLabel=1.0.0 - this would grab the code as it was when the label 1.0.0 was applied. Note: I had issues retrieving to a label with a space in it.

There are multiple gets, depending on what is being built, but they all look like the above target. Building is pretty straight-forward. We use the solution tasks, but they are in different build files. Calling into another build file is pretty simple:

<nant buildfile="MySubBuildFile.build" target="TestBuild" inheritall="true" />

This tells nant to call a target in another build file. This target builds our project in release mode in the dev directories and then copies those files over to the test directories. Those are pretty straight forward, and I've covered them before, so I won't rehash that.

The zip task is also pretty easy:

<zip zipfile="${Project.TestRoot}\Web.zip">
 <fileset basedir="${Project.TestRoot}\Current\Web\">
  <include name="**/*" />
 </fileset>
</zip>

You give a target for the zip, and then tell it what files to include.

Now for the last piece that's a little complicated. Labeling. I've got it set up that you can provide a label on the command line, and the following command will label the repository for me:

<if propertytrue="Project.UseVss">
 <if propertyexists="Project.ApplyLabel">
  <vsslabel user="${Project.VssUid}" password="${Project.VssPwd}" dbpath="${Project.VssRoot}\srcsafe.ini" path="$/CurrentCode" comment="${Project.ApplyLabel}" label="${Project.ApplyLabel}" />
 </if>
</if>

Here's what's happening. First, I check to see if we're using VSS, then if we've supplied a label. If that's the case, then the vsslabel command will label our CurrentCode folder, where we store our current code. Again, I had trouble with spaces in the label. Luckily, I didn't have  to worry about that.

So there you have it. Its' not rocket science, but it is one of the more complicated build files I've ever worked on. Let me know if you have any questions or comments!

I had a conversion with a Brian last week about our build server for Tourney Logic, and he off-handedly asked why we don't buy a development server for all of our projects at NuSoft. I got to thinking about that, and it really is a good idea. Every time we start a project, we scramble to get a dev server up and running, starting from actually finding one. For example, I just went to Dell's site and configured a 1U server with pretty nice specs for less than $1,000. And you wouldn't have to buy one every time, because projects eventually end, and that server could get re-imaged and put back into the server queue.

But what about space? I found a rack that will hold 44 1U servers for less than $500. That's a lot of projects. Yes, you'd probably need a switch to manage them too. So it's not a no-cost solution - probably around $45,000-$50,000 to be able to manage 40 or 50 projects. Expensive, but not excessive.

Now, what could you do with the server? Well, first, each installation would have it's own source repository, as well as continuous integration. The image would have a full-blown development environment preconfigured, even having the ccnet.config file in source control set up to monitor itself, and automatically reinitialize CCNet if your config file changes (allowing addition of projects without having to access the build box directly). More on that in another post. It would even come with a VPC base image that, once the project structure is in place, would be loaded on the server, and each developer coming onto the project could just pull that VPC down and be ready to work on that project. Just keep that image relatively up to date, and getting developers ready to start working on your project is a breeze.

Who knows. Maybe a better solution would be a couple of huge servers, and Virtual Server.

I've been on LinkedIn for a while now, and I just noticed I am connected to 210,000 people out of 2,500,000. I only have 19 connections of my own, but through those 19, I have access to 210,000. 

Only just recently did it occur to me to add other bloggers.

Don't ask me why, but it never really crossed my mind. It took Tim Haines posting about his LinkedIn experience for me to think about it. I sent him a request, and he accepted. Since then, I've also connected with Dave Burke, but like me, he hasn't "gotten it" yet. I haven't gotten it either - so far, it's a nice way to collect contacts, and if I ever have to look for a job sometime, that'll probably be the time it comes in handy, but I'm not looking to do that in the near future.

For now, I'll just build my network. Which brings up another question. What's the protocol for invites? If I read someone's blog, but they have no idea who I am, will it be odd that they get an invite from me? For example, Scoble's a member. I read his blog religiously. Should I send him an invite? What about someone I've just emailed a couple of times? Or should I wait until I've spent enough time on their site commenting that they know who I am?

Or maybe I'll just spam everyone I know! And, if you're reading this, and want to know what LinkedIn is all about, let me know! I'll get you in.

I have a nice headset that I really like. Actually I have two. Both work great, but both work only with my cell phone, and I've been using Skype a lot more lately than I have in the past. I used to use a set of headphones and the built-in microphone on my laptop. No one has complained, but I know the built-in mic can’t be as good as a dedicated headset. But I couldn't find what I was looking for - a converter to allow a 2.5 mm jack to be split into two 3.5 mm jacks. Cell phones use the 2.5 mm jack, while computers use 3.5 mm jacks for the speaker out and mic in. After looking for a while, I finally realized that Radio Shack would probably be the best place - the whole "You have questions, we have answers" thing!

So I went online and found this. It's only $6, and works great! Now I have a nice headset for my computer, and I don't have to carry around another headset with me.

Here's a pretty comprehensive set of instructions on hardening Windows Server 2003 and IIS 6.0. Now that I've recently installed Windows 2003 and have it running on my home network (semi-exposed), this is important to me.

It looks like it'll take a while to get through the whole list - there's 27 steps there, and I'm not sure I'll do all of them.

Reading the latest update from the NTeam about using the Enterprise Library versus other tools, they mentioned they would be using Codus for data access. I've never heard or Codus, but it looks pretty interesting. It's a dedicated data access code generator and works for both SQL Server and Access.

Another product offered by Adapdev Technologies is Zanebug, and I've heard of that one, but not Codus.

I may have to take a closer look at both of these! Anyone else have any experience with either one?

I pulled together a new site design again. This time, I'm much happier with the outcome. The skin is based on the LuxInterior skin for Community Server, which of course I'm not running. But I was able to modify it to work with b2evolution.

I did more than reskin it though. I updated the site to have the navigation on the left hand side, since my posts sometimes go off the screen, forcing my nav to the bottom in the past. I also added links to a few sites that I either use or am a part of, as well as adding a list of podcasts that I listen to. I am also now managing my own blogroll, rather than displaying all of my subscriptions as before. Why? Well, mainly because there's a lot of noise in that list, and I wanted to highlight the blogs that I look forward to reading every day. I added my cell phone number - we'll see how that goes. But if you have a reason to call me, go for it.

I also added a Creative Commons license for my content. I used the least restrictive one, since I post code samples a lot, and think they should be able to be used and modified for whatever purpose you want. All I want is some credit as to where you got your ideas, if appropriate.

So there you have it. Another design - one I hope sticks around for a while. What do you think of it?

Last week, NuSoft Solutions launched their new website. I like the design a lot better than the old site.

It's done in Microsoft Content Management Server, which is something we offer as a solution we'll build for our clients (I was even consulted on the technical design. Not the UI design - that would be dangerous!). I've worked at two places that implemented CMS solutions using Microsoft CMS (or nCompass Resolution), but didn't "dogfood" it. That was always an interesting question in sales calls - you implement CMS for clients. Do you run it on your site? Why not? How do you answer those without losing credibility. In reality, the reason is valid - it's the same reason a carpenter's house usually has a ton of unfinished projects. When you spend all of your time working on other's houses (web sites), you never get your own done.

Anyway, I checked to see if we have a press section, and I found this page, which (as of this writing) has the press release on National City Mortgage's website I worked on. There's also a link to the PDF that'll be more permanent.

By chance, I finally had time to play with the latest version of CruiseControl.NET - twice! Once for Tourney Logic, and once for a client.

It's very nice. I was able to take my existing ccnet.config file and get it working under the new version in no time. Well, not exactly, but that's because I had a lot of work to do on my build files to handle it being in a different directory structure. The ccnet.config for our client

Anyway, I think the new dashboard is much nicer than the old dashboard/web app combo, and much easier to set up. Usually, I'm in Jason Salas' camp about single page websites, and the dashboard application is now all one page, but it works, and that's what matters, right?

There weren't many changes that were needed to get CruiseControl.NET updated, but we did find one interesting issue that didn't appear until we upgraded. We kept getting Exceptions when the build ran, and we finally found the solution - use a different sourcesafe user for each project. We were monitoring 3 projects under the same user, and what happens is a user log file is created when a user logs in, and then deleted when they log out. Well, if the user logs in to check project 1, then logs in to check project 2, and then logs out for project 1, the log file gets deleted, but project 2 still thinks the log file should be there. This causes the build to fail. Create three users, and you're good to go.