We got a new development server last week to handle our source control and builds. We have a copy of Small Business Server 2003, and I installed that last week. Then I got our source migrated over, as well as our build process. I even moved the bug tracker over, now that our server is more stable.

It’s a nice box, but nothing fancy. It's a 2.8 GHz P4, with two 40GB drives running RAID 1, and 512 MB RAM. It's much beefier than what we were using - a 600 MHz desktop machine. I got VPN set up on it, which was nice because I could close up most of the open ports I had to have open before.

Now that we have the server, we should be primed for redesigning and building the Tourney Bracket Control in .NET 2.0. I'm definitely excited about that possibility. And that means we'll migrate the Tourney Pool Manager to 2.0 also, as well as any new products we start working on.

There's a nice article on MSDN about some of the pitfalls and gotchas of debugging ASP.NET applications in VS.NET. If you've ever fired up the debugger and gotten an error, you should read this article.

I've only had one issue that I could never figure out what was going on, and rebooting worked. Those are frustrating. Of course, had I had this, it would have been much easier to find a solution.

I was mentioned on the May 3rd episode of Jason Salas' Digital Pontifications! Thanks Jason. I appreciate the mention. If you haven't listened, you should give it a go. He says he doesn't have a very good radio voice, but that was one of the things I like about his show - he's used to being on the air, and therefore, knows how to handle broadcasting to an empty room.

Jason and I have a little bit of history, so it wasn't a complete surprise to be mentioned on his podcast. He contacted us back in January or February about using the Tourney Bracket Control a site he maintains. He ended up using it, and had a nice pool running on his site.

But it doesn't stop there. He asked Brian and I to come on his sports talk show before the NCAA tournament. We did, and I thought it went pretty well. He was going to record it, but a technical glitch prevented it, so he promised to have us back on. I think it was supposed to be this past week, but I'm not sure if Brian was on or not.

And as if he hadn't done enough for us, he's now asked me to come on to his new ASP.NET show, which I am very excited about. I can talk about sports fairly well, but I can talk about web development like I can talk about my own kids! I have no idea when I'll be on, but as I get more information, I'll post it here.

Scott Mitchell has another great article on the 4Guys site about why he doesn't use Datasets in ASP.NET applications, and then lays out why he doesn't. It's a good read, and reflects most of the reasons we decided to use custom objects and data readers instead of Datasets on my last project.

Having talked with another project using datasets, I'm glad we made the decision we made. Working with datasets on a web project seems to me to be more hassle than it's worth.

Oh yeah. You should also read through this blog post, where there's quite a few comments on both sides of the isle.

UPDATE: I wrote this, and hadn't had a chance to publish it, but Eric Wise has a post saying he uses them for simple display of data, because he doesn't want to have a database connection in his UI code. I think one of the things he said is false though - that creating a collection of those values with custom objects is slower than binding to a data table. From what I saw, Scott's article refutes that claim. Either way, we got around having to make the decision by caching look up tables that are used in drop downs, using the same custom object for all of the different look up tables, and using database cache invalidation.

UPDATE, PART 2: Man, I need to start publishing these things faster! Eric has updated his post to include some data.

Rocky Lhotka has an interesting article about SO Design, and how the current state of affairs of SOA implementations and the tools we use to develop them. Basically he says that because of how the tools deal with web services, the way we develop web services is flawed, and we should be using covenants on top of contracts.

If you don't read the article, here's what he's talking about. A contract is the API you use to call the web service, where as the covenant is the agreement you make - i.e., if you give me this, I will do that. He's basically saying that the API shouldn't be strongly typed. Basically, he's saying your API should be:

responseMessage = MyFunction(requestMessage);

Then you can put whatever you want in the requestMessage and get whatever you want back in the responseMessage. It's an interesting idea. Your service API never changes, but you can allow newer clients to use your service. You just specify a new covenant.

UPDATE: I started writing this, and was going to talk about the problems with using an untyped requestMessage and responseMessage, but reading Rocky's blog, I came across his latest post, where he linked to an article on SRT Solutions that talks about how to use abstract classes in web services and accomplish the above solution and get type safety. Very nice.

Coincidentally, the article on SRT Solutions was written by Bill Wagner, who works with Josh Holmes. I posted about a presentation Josh was doing in Grand Rapids back in December, and if I remember correctly, he actually came over to my desk and thanked me for the link. I had completely forgotten about that until I found this article today!

The ASP.NET 2.0 quickstart tutorials are in beta on www.asp.net. With .NET 1.0, these quickstarts are what I used extensively to learn my way around .NET. I'm sure I'll be using these as I move forward with ASP.NET 2.0, which I am hoping to start working with soon.

Also, it looks like there's a beta version of the asp.net site. I like the new look.

I haven't messed with AJAX yet, and I don't have any immediate plans to do so. For those not familiar, AJAX stands for Asynchronous JavaScript and XML, although it's most famous use is in the cool interface for Gmail (I still have invites if you want them!).

Anyway, over on the Apress blog, Harshad Oak has a post asking if it's even worth adopting. His points really hit home after dealing with a fair amount of Javascript on my last project. Basically, he asks how can we expect to get cross-browser support for AJAX if we're already struggling to get cross-browser support for basic HTML, Javascript, and CSS now? He makes a very good point. I can see using AJAX on an intranet where you can control the browsers used, but out in the vast internet space, I'm not so sure. I guess you have to do what Google does - provide an alternate version.

Having said that, if you want to work with AJAX and ASP.NET, you'll want to read this blog. He wrote AJAX.NET, a wrapper for working with asynchronous callbacks and .NET.

UPDATE: Here's another AJAX implementation for ASP.NET.

Jeremy has a couple of nice posts about test driven development that, if you are looking for newbie advice on TDD, you should read. The first one talks about designing with TDD in mind, and the second discusses the advantages of high cohesion and loose coupling.

He also has a nice post about alternate tools to VSTS. A lot of these tools will be used (if it comes to fruition) to make NTeam.

Doug over at The .NET Buffet has a post about an end to end application using the Enterprise Library. I still haven't had the time or the opportunity to dig into the EntLib, but this application may be a chance I get to dig in.

I missed this a while back. This post was from February. I guess I should stay on top of these things a little more!

MSDN now allows you to download their webcasts for offline viewing. There was a workaround for this a while back, but this is much easier - you can download it as a WMV file.

Now I can download the webcasts on the Enterprise Library that I am interested in, and view them whenever I want - on a plane, riding in a car, or wherever suits me. Nice!

UPDATE: On the Enterprise Library note, here's a site with all of the webcasts from the Patterns and Practices team. They're the guys who wrote EntLib.