Title Image

Don Xml's Grok This

The home of Don Demsak
Welcome to Don Xml's Grok This Sign in | Help
in Search

This Blog

Syndication

Site Sponsors

DonXml's All Things Techie

Visual Basic .Net 2005 Project Guidelines For Enterprise Development

I’ve been doing a lot of documentation for my personal style of building enterprise application using .Net 2.0 (sort of extensions to the book Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries by Krzysztof Cwalina and Brad Abrams), and I thought I’d share this one with everyone.  Some of my readers may already know that I like to make Visual Basic .Net feel more .Net like, with less of a focus on the overall looseness of its heritage (and I developed for years in VB 3 thru VB 6).  Remember, these guidelines are for building enterprise applications, not rapid application development (RAD) applications.  When building something in a RAD style, I use the standard Visual Studio configuration of Visual Basic.

Visual Basic was around long before .Net, and for backwards compatibility, some concessions were made in the Visual Studio IDE to accommodate backward compatibility.  Since we are now in the third version of VB.Net, it is about time to cut ties with Visual Basic 6, and embrace the .Net framework when building enterprise applications (these guidelines are not intended for rapid application development).

Do set the project property “Option Strict” to On.  This option is set in the Compile tab of the Project Properties

Do set the project property “Option Explicit” to On (this is the default).  This option is set in the Compile tab of the Project Property.

Do remove all references not needed (a number of references are included by default that may need to be removed).  This option is set in the References tab of the Project Properties.

Do not use project level imported namespaces.  Instead, put the import statement for each required namespace at the top of every class file.  This option is set in the References tab of the Project Properties

Do not use the Microsoft.VisualBasic library if there is an equivalent function in the base .Net framework.

Do not import the Microsoft.VisualBasic at the class level, and instead fully qualify each use of the Microsoft.VisualBasic library.  Besides helping enforce the use of the base .Net framework classes, this will also help the developer recognize when they are using a Visual Basic only feature/extension.

I’m sure some Visual Basic purists out there will cringe at my guidelines, but, as I said, this is the third .Net version of the language, might as well cut the backward compatibility to an old version of the language when you are building enterprise applications.

Published Wednesday, August 30, 2006 1:12 PM by donxml
Filed under:

Comment Notification

If you would like to receive an email when updates are made to this post, please register here

Subscribe to this post's comments using RSS

Comments

Scott said:

I really don't consider myself a VB purist, but do find myself cringing at the "Don't use the Microsoft.VisualBasic library if there is an equivalent function in the base .Net framework." I was with you man right up to the last two x's. But, then again, you did qualify the blog with "my personal style" :-)

This "don't use VB stuff" is really just a personal pet peeve of mine. But, if I'm making a decision to write VB code, I think it makes sense to take advantage of VB things, same goes for C# or maybe someday soon Ruby.Net. For some reason, VB seems to always fall into the shadows of being the ugly .net child. Personally, I love the fact that different languages are different languages. Microsoft made a decision to compile everything to IL, but to the best of my knowledge not to do away with higher-level language abstractions or libraries. When it comes to other languages, terms like elegant are used for unique language niceties, but when it comes to vb everyone seems to think of terms like "supporting backward compatibility."

If I'm writing VB.Net, I personally much prefer Right(s,3) instead of s.Substring(s.Length –3, 3)), but thats just me.
August 31, 2006 12:04 AM

Adam said:

I agree with Scott because VB has always been a language and a set of runtime libraries. VB.NET is really no different. Many of the VB.NET functions and helpers make some of the more tedious stuff way easier. And don't get my started about the "My" namespace (My.Computer, etc). I don't *need* it, but I wouldn't mind having the equivalent in C#.

However, I agree with the original also because I don't really plan on ever writing code in VB.NET either. If I did, however, I would most certainly stick to the C# way of writing code and forego the VB.NET helpers.
August 31, 2006 10:56 AM

Kent Brown said:

I completely agree with Don. I've been taking this approach since .NET 1.0. While I don't hide my VB heritage, it's best to embrace .NET because you might be on a C# project in the future or a C# guy may someday need to maintain your code.
September 14, 2006 8:19 AM

Leave a Comment

(required) 
(optional)
(required) 
Submit

About donxml

I’m an independent consultant, specializing in .Net solutions architecture, based out of New Jersey who also doubles as an evangelist for XML, Domain Driven Design, enterprise architecture and .Net. I do not work for Microsoft, the W3C or any other big company that you may know of (at least not yet). I’ve been an indie for over ten years, and although I’ve been tempted a couple times to take a job with companies like Microsoft, I’ve haven’t found something better than my current situation. I work mostly with the large pharmaceuticals that are based here in New Jersey, and usually find myself on long term contracts. Definitely not the prototypical indie consultant, but it lets me dedicate time to my non-income generating activities like the developer community stuff, plus financing open source projects like XPathmania and MVP-XML. If you would like to talk to me about doing some contract work, just contact me via the contact page. My rates vary widely, depending on lots of different variables, but mostly distance from Jersey, and type of work. Plus, I’ve been known to donate some of my code for various projects.
Powered by Community Server, by Telligent Systems