Deploying Critical Solutions With .NET

Readers who have made the leap to .NET aren't looking back. They say they're developing and deploying reliable, mission-critical apps that pay for themselves quickly.

• By Readers of Visual Studio Magazine
• 08/01/2005

Letters to Visual Studio Magazine are welcome. Letters must include your name, address, and daytime phone number to be considered for publication. Letters might be edited for form, fit, and style. Please send them to Letters to the Editor, c/o Visual Studio Magazine, 2600 El Camino Real, Suite 300, San Mateo, CA 94403; fax them to 650-570-6307; or e-mail them to [email protected].

Deploying Critical Solutions With .NET
Like Peter Banks, I am also one of the "in-the-trenches developers" [Letters to the Editor, ".NET: Too Little Progress," May 2005]. We don't care much about Web service calls, SOAP, XML, Pocket PC, intranets, extranets, or writing objects that run on $25K+ servers.

We do care about customers and solving their business problems with easy-to-develop, natural-to-use Windows apps that are cheap and pay for themselves quickly.

While I took my time to make the initial leap to .NET, I can happily say I haven't looked back. I have found .NET to be the most productive environment for developing stable, reliable, value-for-money software solutions for customers. I can create these solutions more quickly, with less bugs, and with less deployment headaches.

Best of all, the language and environment have been stable. There is no new version (with all new idiosyncrasies/bugs) every three to six months. There's no need to rewrite all of that support code (my toolkit, so to speak). There's no need to continually upgrade components, coding standards, or database access technology. Windows XP has standardized the desktops we support, and now SQL Server 2000 has standardized how our customers' data is stored. I can reliably develop internal documentation, tools, and standards that will be meaningful for longer periods of time and won't need to be rewritten before the ink even dries.

I'm looking forward to the new 2005 versions of all the tools. My hope is that the changes will help those at the bleeding edge and will only slightly impact those of us doing the "real and meaningful work." (I'm not even going to install a release candidate to a virtual PC until there is a clear date for release.)

While progress is a great thing and I'm all for development and improvements (I, too, miss edit-and-continue), I'm glad that the rate of change has reduced. I can concentrate on developing solid solutions using my existing code base, and in the end, make money—instead of having to "reinvent my wheels" every 12 months.

And don't forget, just after VB3 there was VB4, and the mess that created. I believe this is when the fires of DLL Hell were lit.

Andrew Way, Adelaide, South Australia

I am amazed at how people are so compelled to compare the age of innovation in VB.COM with the age of conquest in .NET.

VB.COM was a unique time. But the attraction was in the perceived notions of rapid development and implementation of a business solution. The operative idea here is "implementation of a business solution." I know memory is selective, but come on folks, the old IDE was sweet and the code ran nicely in the debugger, but trying to deploy one of those things in a production environment ? well, you were there.

I left VB.COM for C# and never looked back. I have written and deployed countless enterprise business applications using .NET. We are talking true object-oriented programming. You can't be serious about VB.COM. I would never go back, not in a million years.

What Microsoft has done with .NET is nothing less than amazing, and I am not just blowing smoke through "The Gates." The stuff actually works, and works well. My proof is that .NET has been running our company for the last three years. We have designed, developed, and deployed large, critical business solutions: point of sales, inventory and distribution, and sales and marketing applications integrating seamlessly with our ERP and data warehouse. This could not have been accomplished in such a short time frame without the new technologies and efficiencies that .NET brings to the table.

Like the forward-thinking support communities that have brought tools such as NUnit, NDoc, and CodeSmith, .NET is unstoppable.

So, live in the nostalgia of VB.COM, or join us in the future that is .NET.

Paul Svensson, Plymouth, Minn.

Classic VBers Are No Joke
Oh, please let me go first.

Originally, I thought you were doing one of those parody editions, but after reading through Karl E. Peterson's guest editorial, I recognized the desperation of a frightened coder who is having a difficult time moving on [Guest Opinion, "Support Classic VB," May 2005].

After three years of fulltime C#, the aesthetic centers of my brain recoil at such nostalgia.

Karl, walk to the light. It is OK to let go.

Paul Svensson, Plymouth, Minn.

This opinion deserves only one response: Evolve or die!

Most Classic VB code I've come across isn't worth keeping around anyway and should be rewritten in C++ or C#. Most of the developers I've come across who argue to keep the existing tools long after they've become productive are afraid to learn anything new or simply can't keep up with new technology.

Classic VB does have its place—in the exhibit down the hall from Cro-Magnon man and the Apple IIe and all of the other evolutionary steps we've leaped over to reach our current progress. (C# will eventually be there also.)

Mark Nischalke, Cranberry Township, Pa.

VB6 (Classic VB) is as dead as QBasic, and I do not miss it.

I've been a strong VBer since QBasic, and every new rendition that came out was always better. Sure, there was a learning curve, but that's the price of being a developer. Either keep up with what's coming out, or become stagnant pond water just like the old Cobol, Fortran, and C guys did. Face it—COM will be gone in the next few versions of Windows. What will the VB6ers do then?

As soon as the first beta for 1.0 came out, I was getting my hands dirty, learning something new. It was tough at first, especially getting rid of the bad habits that VB6 encouraged. But it paid off in a big way, and it allowed my company to release a product that never could have existed under VB6. I was a hard-core VB6er; I knew all the workaround hacks. But I will not look back. My life is so much easier since I adopted .NET.

I understand some people have large groups of customers to support under their old code base. But why bother for new development under an outdated system? Or are these the type of developers who are scared to learn something new? I don't know.

I love how the .NET code flows. Heck, I can read and write C# code, because it's the same as VB.NET with just some syntactic sugar on top. I no longer feel like I work with a second-class language, because I can do anything C# can do.

Matt McGuire, Yakima, Wash.