GenXJamerican

I decided to post on this topic today because of an article I saw on the printer at work this morning. You can check out the entire article yourself here, but what made me decide to post was the author’s assertion that VB.NET can be “considerably less verbose than C#” because of the “with” keyword. He left out the existence of the “using” keyword in C#. The code he writes as an example could be simplified to the following:

using (TabPage tp = tabControl1.TabPages[0]){ tp.BackColor = Color.Red; tp.BorderStyle = BorderStyle.Fixed3D; tp.ToolTipText = “Click Me!"; tp.Text = “Hello world”; }

In C#, the keyword does double-duty by indicating inheritance from .NET and COM libraries. In VB.NET, another keyword (Imports) is needed for this task.

The author is right about the existence of more automatic formatting and IntelliSense code-completion in VB.NET. However, I consider it more a hindrance than a help when creating properties. In C#, if you want to create a read-only or write-only property, you write the property with just the get block or the set block. In VB.NET, you’re required to provide a ReadOnly or WriteOnly keyword to get the same effect.

The initial reason I decided to learn C# instead of VB.NET is a demo I saw from Don Box at a Guerilla.NET class in 2001. He took a MS Visual C++ sample app and used the .NET Framework to compile it. He didn’t have to change a single line of code to get this to work. He said at the time that this was the only language that trick was going to work for. He turned out to be right.

Early on, another argument in favor of C# was the number of code samples and books. It seemed heavily in favor of C# versus VB.NET, though the gap has certainly narrowed in subsequent years.

A third argument in favor of C# is what language software products are being built in. I heard plenty of rumors in 2001 about Microsoft rewriting some things in C#. But what’s certainly true is that some companies are building products with C#. Writely, a recent acquisition of Google, is written in C#. Community Server, from Telligent, is also written in C#. NUnit, an excellent unit testing tool (ported from JUnit), is also written in C#. NAnt is a C# port of the Ant build tool.

Mine is just one opinion among many as to whether you should use C# or VB.NET. But when there’s a development team involved, the language to be used should be the one the majority of developers are familiar with. That’s why I chose VB.NET when building MethResources.gov even though I personally prefer C#.

Here are some other opinions on the subject: Choosing between Visual Basic .NET and C# (by Ted Pattison) From VB.NET to C# and Back Again (by Darren Neimke and Scott Mitchell)

Back in April, at the end of my first post on the topic of “open source .NET”, I’d written that the next post in the series would be about Community Server. Telligent released version 2.1 of their flagship product just last week.

I first found the product at the end of 2004, when it was still Community Server: Forums. My employer was bidding on a project to provide an online forum to one of our government clients. One option they were considering was to make a copy of a custom online forum they’d already done for another client and modify it to suit the new requirements. This option reminded me of two things I dislike most about custom development:

• "Cut-and-paste inheritance"
• Reinventing the wheel--badly

It didn't take too many Google searches before I found Community Server: Forums and put it forward as an alternative. The next few paragraphs will discuss how I felt the product stacked up against "the four questions".

1. Is open source the best choice for this application? Because of how long online forums have been around, open source is a particularly good choice for this application. I came across a pretty large number of options for online forums when I was searching. That said, a number of them were written in languages like PHP or Perl for UNIX (which helps answer question 2).

2. What platform are your developers most skilled at building for? As a Microsoft shop, trying to deliver a customized solution on a platform the developers weren’t familiar with was far too high a risk. This eliminated a significant number of the applications I’d seen.

3. Is the best open source application on the .NET platform? In 2004, I would have said no. To me it seemed more likely that the best open source forum application would be on UNIX, simply because of longevity. But given what the developers we had were familiar with, and the alternative of cut-and-paste inheritance with a classic ASP solution, Community Server: Forums was the best for our purposes.

4. Is it our goal to re-sell an application we’ve extended? Unlike our experience with IssueTracker, the objective of making money with modified versions of this application was clear from the very beginning.

There are two “barriers to entry” with Community Server that proved significant in our case:

• C#
• Documentation

While I had made a deliberate choice to learn C# instead of VB.NET back in 2001, the vast majority of the developers I had to work with had moved to VB.NET from VB. The lack of familiarity with C# syntax led to a number of suboptimal choices for customizing the look, feel, and functionality of a particular instance of Community Server. The relative lack of documentation (both in the source code and stand-alone) made it a challenging platform to extend. I suspect that some of this is by design, as Telligent still makes some portion of their income from custom implementations of Community Server.

On the plus side, Community Server is quite well-built. Its naming and architecture are consistent enough that it took me relatively little time to customize a version of it for my most recent project: pushingback.com. The site is customized in a way that would make it quite easy for us to upgrade the site from Community Server 2.0 to 2.1 if requested. If the companies that currently use it are any indication (Microsoft, Dell, MSNBC), it’s one of the bigger (if not the biggest) successes of open source on the .NET platform. In my next post on this subject, I’ll discuss an issue that seems unique to open source on .NET–competing products from Microsoft.

I was actually searching for information on how to add dynamic pages to a Community Server 2.0 installation when I came across this post.  While I don’t need static pages for my current project (yet), this information probably saved me hours of unnecessary work.

I saw this insightful article on the subject in a “most popular articles” list. The author, Douglas Reilly, acknowledges at the beginning of the article that he uses stored procedures virtually all the time, but still does a great job of describing the pros and cons of each approach.

The most useful thing the article taught me was that as of version 7, SQL Server keeps execution plans for all statements, not just stored procedures. This reduces the advantage of stored procedures for basic CRUD (create, read, update, delete) operations substantially. I’ve certainly touted the superior performance argument in comparing stored procedures to ad-hoc SQL before, so I’m glad I learned the real deal now. That said, I still hold a bias in favor of stored procedures. Once upon a time, I worked for Sybase Professional Services as a DBA, and they were definitely pro-stored procedure. Nearly every shop I’ve worked in since then has been similarly inclined. Anytime an employer has used ad-hoc SQL, it’s been absolute murder to maintain. In my experience, the maintenance advantage of stored procedures over ad-hoc SQL is substantial, not slight (as Reilly concludes).

One issue the article doesn’t bring up that might be interesting is source code control for stored procedures and other database elements (views, user-defined functions, etc). While SQL Server does have backup and restore, it’s not nearly as granular or convenient as the check-in/check-out model of today’s source code control systems. On my projects, I tend to generate a script with just the stored procedures in it and store that in SourceSafe. I’d certainly like a better solution, but haven’t found one yet. I’m curious to see what SQL Server 2005 is like, since it will allow you to write stored procedures in C# or VB.NET.