The last 2 days I had a lovely time upgrading a major project we work on at BrightMix over to Visual Studio 2008. Actually, the code upgrade was totally automated by VS2008 so that was easy. The hard part was getting VS2008 Team Foundation Build Client to play nice with our Team Foundation 2005 Build Server (abbreviated as TFBS from now on).

Oh, the Trials And Tribulations...

The first thing you find out is TFBS can't figure out how to build 2008 solutions. You'll see something like this in your build log file:

Build FAILED.
C:\Builds\TFSNow\TfsNow-PublicWebsite-Continuous\Sources\PublicWebsite.sln(2): Solution file error MSB5014: File format version is not recognized.  MSBuild can only read solution files between versions 7.0 and 9.0, inclusive.

Fortunately, Mitch Denny has a great post detailing out how to fix this issue. Following Mitch's post, I upgraded the build server from .NET 2.0 to 3.5 and replaced the .NET 2.0's MSBuild.exe with a dumby MSBuild.exe that redirects to .NET 3.5's MSbuild.exe. Fun times. For your convience, here's the dumby .NET 3.5 MSBuild executable that I used (note: mine is hardcoded to redirect to C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe - you'll have to compile your own if you need it to go someplace else).

Next Problem: Deploying Web Applications

After I got the dumby MSBuild.exe in place, I fired off a test build and another error showed up in the log:

error MSB4019: The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v9.0 \WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.

The problem is with an <import> declaration in the Web Application Project's .csproj file. Basically, the "Microsoft.WebApplication.targets" file doesn't exist on the build server because it only has TFS 2005 installed.

I ran across a couple of helpful blog posts for this problem: Steve Harmen demonstrates a fix to the Web Application Project's .csproj file that involves adding another <import> declaration and some conditional logic. So, I added that in and, sure enough, the test build was now successful.

Surprise! Another Problem!

However, I quickly discovered that the Web Application Project's files (.aspx, .html, binaries, etc.) were not getting deployed to the test server's drop location. Some further digging revealed that some other people have had this problem, but no one had come up with a solution.

My Final Solution

What I ended up doing to get this working was leaving the <import> declaration in my Web Application Project's .csproj to point at the VS2008 directory (the one with "v9.0" in it). Then, I simply created that directory on the build server, since it didn't exist, and I copied the v8.0 "Microsoft.WebApplication.targets" file into the newly created "v9.0" directory. This probably isn't the best solution for this problem, but it seems to work.

If anyone has feedback on this, please leave a comment!

This is part 3, the last post in my Rails VS ASP.NET series. Please see Post #1 and Post #2 if you missed them.

In my previous post, I mentioned that I have a glimmer of hope for ASP.NET. This post is about the current state of ASP.NET, what it's doing right and, moreover, what direction I want to see it go.

The Alt.Net Movement

A community, dubbed Alt.Net, formed around providing solutions to a number of programming concepts that the .NET framework lacks. Particularly pressing is the lack of an MVC framework for ASP.NET. Fortunately, some smart developers out there cranked out a solution to the MVC problem: Monorail, a replacement for ASP.NET's out-of-the-box Webform architecture. Monorails gained a lot of popularity, but , as a 3rd party product, its adoption has been limited. I mean, most ASP.NET devs out there that I've talked to have never heard of it.

As a side note, I think it's worth pointing out here that if a ASP.NET has disgruntled enough programmers out there to the point where they've band together and created their own framework to fix/extend the current architecture, it seems like a good indicator that something is horribly, terribly wrong.

Most recently, Scott Gu announced Microsoft's solution to ASP.NET's MVC conundrum: the aptly named ASP.NET MVC, which is being bundled into the ASP.NET 3.5 Extensions library.

Yoink! We got MVC Now!

How does this play into Rails? Well, one could claim that Microsoft's implementation of the MVC pattern and associated URL routing structures are freakishly similar to that of Rails. Like really, really similar. It doesn't really bother me that Microsoft is making ASP.NET MVC mimic Rails. In fact, it's a great indicator that Rails is on the right track (pardon the pun). I just wish they'd go a bit further and implement the concept of Rails Partials and also extend the Microsoft Ajax Javascript Extension library to be more like Prototype.

Hmmm... Why Use ASP.NET?

If you've done much Rails development, you'll quickly discover that the majority of Rails developers out there use a Mac as their development platform and TextMate as their preferred IDE. I recently joined this bandwagon, and I will admit that it's a pretty sweet set up. Damn you, Apple, for making your MacBook Pro's so attractive!

Anyway, so one thing that sucks about Rails development, especially if you're just learning, is you don't have access to the all-knowing Intellisense to help you along. The latest versions of Visual Studio, and by that I mean 2005 and up, have some very kick ass, easy-to-use Intellisense that helps out not only with .NET code but with CSS and Javascript. Of course, TextMate has the concept of Bundles, which are very powerful, but basically require memorization of Hotkeys to be useful. There's also the NetBeans IDE for Rails, which has some decent Intellisense, but nothing on par with Visual Studio's.

Another thing .NET has going for it is its immediate availability of "Enterprisey" level things, such as message queuing and transaction scopes. It's also great for working with old Com Objects and the like (*shudder*) This comparison post has more details on the subject.

Another situation in which Rails would be a weak choice: say you need to create a new web app that talks to an old legacy database. The Rails ORM, ActiveRecord, is built around the assumption that your database will be created in parallel with the Rails application and follow a strict set of naming conventions. You're going to run into some major setbacks if you try to use Rails for this scenario. However, with ASP.NET, you can easily use ADO.NET to handle this problem much more quickly and efficiently.

I certainly won't claim to know every situation in which one framework might is better suited than the other. Leave a comment if you can point one out!

Rails Vs. ASP.NET Wrap Up!

I could keep going on this subject, but I'm going to stop myself here. I've talked a lot about the problems I've experienced with ASP.NET and a number of the reasons why I believe Rails is currently a far superior web framework. If I had to slim it down to 3 reasons why Rails is better, they would be:

• Integrated ORM
• Convention over Configuration
• Integrated Javascript Library

If you're currently a hardcore ASP.NET dev, like I used to be, I greatly encourage you to take a look at Rails and play around with it a bit - I guarantee it will be an eye-opening experience. Actually, you might not want to; once you get a taste of Rails, you'll likely not want to go back!