Shane Bauer - ShaneBauer.com - Home

Upgrading to Ruby 1.9.1 for Windows

2009-02-09T18:04:00Z

I spent some time upgrading to Ruby 1.9.1 not too long ago. For Ruby/Rails devs using Windows (I know there a few of you closet developers out there), if you're using the 1.9.1 preview binary, you need to add the DLL dependencies yourself. For some unknown reason, they did not package the required DLLs with the package. If you have 1.8.7 installed, you can copy the DLLs from that install's bin directory and place them into your Ruby 1.9.1 bin directory. Here's the list below. Note the change in file names for the zlib directory.

-> [Ruby 1.9.1]\bin\libeay32.dll
-> [Ruby 1.9.1]\bin\readline.dll
-> [Ruby 1.9.1]\bin\ssleay32.dll
-> [Ruby 1.9.1]\bin\zlib.dll

I know Ruby/Rails wasn't designed with Windows in-mind, but if you're going to make it available, at least package the dependencies for it.

Subversion, TeamCity, and Rake = Wow

2008-10-29T02:51:00Z

Whenever I start a new project there are certain things that I always need to do. I need to setup the source code repository, create a basic project structure, create a build script to build the project, and setup the project on a build server.

A few months ago I realized just how much I hated doing all of this. Setting up the repository was the easiest part. I've been using Subversion for years. Instead of hosting my own subversion server, I use a third party. I'll let them manage the server, subversion upgrades and the backups. Because of this, setting up the repository was basically logging into a control panel, filling out a form, and that's basically it. However, after this was completed, the tasks became much more redundent.

For the longest time I used NAnt for my build engine. It is a good tool, no doubt. The problem is I hate XML. I hate it. It's not the language itself really. It's how people use XML. NAnt uses XML as the way to write the build script. I hated creating the scripts and I hated modifying them.

Of course, my XML troubles didn't end there. I used CruiseControl.net as my CI (build) server. The application itself is OK. It's not great and has aged quite a bit. By far my biggest problem with CC.NET is the process of adding a new project. In order to add a new project to CC.NET, you must modify an XML file. If you have many projects configured, that file may be quite large.

I don't know about you, but after setting up my build script and setting up the project in CC.NET, I'm pretty tired of looking at XML.

Taking a look at TeamCity

After reading a ton of blogs and twitter messages from people talking about TeamCity, I decided to give it a shot. I wasn't really sure what to expect. I thought it would be good as I'm a huge ReSharper fan (the same company that makes ReSharper also makes TeamCity), but didn't really know if it would fit my needs.

Fortunately, JetBrains (makers of TeamCity) markets a version of TeamCity targeted for smaller teams that doesn't cost a thing. I grabbed it, installed it on a VM, and played around. To make a long story short, I'm still using it. TeamCity is a really nice CI server. It's very extensible and configuration is a breeze. You can add projects and build configurations straight from the browse. No need to modify XML files. TeamCity supports a number of different version control systems and build environments out-of-the-box. NAnt, MSBuild, Ant, and command-line are just a few. Because of this I was able to migrate my project from CC.NET to TeamCity in no time.

Replacing NAnt with Rake

After deciding to go with TeamCity, I felt pretty good. I had solved one problem. I cannot tell you how much time I've saved because of it. After a while, though, I started to look for replacement options for NAnt. Like I said before, I like NAnt, but I wanted something better than XML. After doing some research, I decided to look into Rake, a build tool programmed in Ruby. I noticed a few .NET developers using Rake successfully. One evening I loaded my NAnt build script and replicated the entire script using Rake. I've done some work in Ruby so it didn't take that long to convert everything over. Obviously, you don't have the pre-made nant tasks, but creating a reusable framework that calls the executables for various tools (msbuild, nant) wasn't too bad. After I got it working locally, I modified my existing build configuration in TeamCity to call the new rake script. Initially, I used the rake runner in TeamCity. After a while, I wasn't getting the results that I wanted so I switched to the simple command-line runner. After tweaking a few minor things, I was done.

Looking Back

I'm really satisifed how things turned out. TeamCity is a joy to work with. Managing Rake build scripts instead of XML files just feels right. If you're looking for a replacement or you're just getting into this territory, you should really take a look at TeamCity and Rake.

ASP.NET MVC: Testing Controllers Using the Pre-Preview 3 Drop

2008-04-22T14:49:00Z

A week or so ago, I wrote an entry about controller testing with the ControllerBuilder. In it I mentioned the "solution" obviously wasn't the best, and hoped that the work-around we were using wouldn't be needed for much longer. Well, last Wednesday the MVC team published a preview of preview 3. There were a number of changes included in this build, but I'm going to talk about controller testing improvements.

What We Did Way Back Last Week

Last week, we used a test helper from the MvcContrib project. Basically, the controller builder constructed an instance of our controller using Dynamic Proxy and then implemented an interceptor so it could grab data that we could use in our tests. It is quite a bit of work for something so straightforward. All we wanted to do was execute our action and see if it rendered the correct view.

What's My ActionResult?

If you remember, our controller actions are nothing more than public methods on a controller class. When you call the action from your browser, the ASP.NET MVC simply wires up a request that eventually executes the specified method. Nothing too crazy. The methods didn't even return anything; they were simply declared void.

Since we're working with preview releases here, you can't really expect things not to change. With the latest build, controller methods/actions now return an instance of ActionResult. What is ActionResult? ActionResult is an abstract class that is used to return the result of the action. A result can be a rendered view, a redirect to an action, or even a regular HTTP redirect to another location entirely.

Getting the Result

Now, here's where you may notice the difference. In our previous controller code, if we wanted to redirect to an action, we could just call RedirectToAction in the middle of the action code and be done with it. RedirectToAction, and the other helper methods, all return instances of some form of ActionResult. RedirectToAction now returns ActionRedirectResult. RenderView returns RenderViewResult. What does this mean? When you call the helper methods, you need return their result now. Here's an example:

public ActionResult Index()
{
    return RenderView("index");
}

As you can see, you just need to ensure you return the result. This result is then used by the framework and you can also use it for testing. The code below illustrates a very simple test using the new build.

[Test]
public void BookController_Ensure_Index_Action_Renders_Index_View()
{
    BookController controller = new BookController();
    var result = controller.Index() as RenderViewResult;
    Assert.IsNotNull(result);
    Assert.AreEqual("index", result.ViewName);
}

I'll have more on this subject, and a real world example that puts them all together in a little while.

ASP.NET: Web Controls have an ID, a ClientID and a UniqueID. What's the deal?

2008-01-07T03:56:00Z

While working on your ASP.NET page, you may have noticed that all of your web controls contain three different ID properties. That's great. But why? Uniqueness.

Lets say, for example, you have a Repeater control. In this Repeater control, you have an itemtemplate that contains a textbox and a label. Your label is called "ProductName" and your textbox is called "ProductQuantity". If your repeater contained more than one item, you would run into issues with html elements being named the same. That's a huge problem.

UniqueID fixes this issue. When the control gets created, a uniqueId is generated based on the control's heirarchy. For example, a textbox within a CreateUserWizard would have a UniqueID similar to "CreateUserWizard1$CreateUserStepContainer$Email". The UniqueID, as you can see, is a large string seperating the control's parents by a dollar sign. Pretty simple.

However, that's not technically valid in the HTML world. ClientID fixes this problem. ClientID replaces the invalid separator with a valid separator, like an underscore. Therefore, the textbox within the CreateUserWizard would have a ClientID similar to "CreateUserWizard1_CreateUserStepContainer_Email". As a result, when your textbox is rendered as a standard input element, the ID field would contain the value in the ClientID property.

If you want to access your control via javascript, don't use the ID property, and don't use the UniqueID property. Use the ClientID Property.