"VB.NOT" vs. VB.NET

Even before the arrival of the very first release of the new Visual Basic.NET language late last year at Microsoft's PDC (professional developers conference), rumors of big change for the new VB.NET were rampant on newsgroups.

Beta 1 of Visual Studio.NET seemed to confirm some of our worst fears. A lovable programming language that was known for its ease-of-use, convenience, and ability to hack out code quickly (as well as build high-end business objects) was, at first glance anyway, pulled right out from under us. It's doubtful that Microsoft could have anticipated the level of vituperation (and ornery love for the little programming language that could) in developer newsgroups reacting to changes in store for the new VB.NET.

The fact is VB is a language that everyone at one time or another has wanted to tweak. We all wanted to remove this feature or add that one. For example, how many of us wanted real inheritance in the language, and listened to Microsoft over the years from VB 4 to VB 6 explain why mere composition was good enough? Warts and all, VB was a language that had its own spirit and sensibility. It had an ethos for many programmers of getting the job done fast, even if we knew in our heart of hearts that our code was a bit of a hack. (This writer has written thousands of lines of VB code for production systems in a small team and could not imagine being successful with any other language in such short project cycles.) Time and again, VB just works, period.

Over the years, Microsoft has extended VB's original modest capabilities beyond simple client forms, and in version 6, this one-time hobbyist's tool was just about all grown up. It was VB 6, after all (and not C++) that became the premiere tool for building business objects in Microsoft's DNA strategy for creating scalable Web applications.

Things change, and how! Last year came the announcement and first preview release of VB.NET, which quite literally breaks every one of those thousands of programs (with millions of lines of code) written in VB 6. Early samples from Microsoft showed us a new Visual Basic that did not look like at all like Visual Basic code. Well-respected VB gurus of the old school weighed in and pronounced that this new doppelganger wasn't VB at all, but a sort of futuristic, soulless ghost.

Bill Vaughn, an ex-Microsoftie and author of several books on VB weighed in said that VB.NET wasn't really VB. Call it Visual Fred, he wrote in a newsgroup, and that would be closer to the truth. (This quip is surely one of the most clever and surreal takes on the situation. Much of the rhetoric was overheated by all too tiring flames). Another VB expert, Bruce McKinney pronounced VB dead, and wrote its epitaph, along with a requiem for his once must-have book, Hardcore Visual Basic. Another name for the new VB was VB.NOT, and one VB aficionado compiled a list of over a hundred language features not supported in the upcoming release. Worse yet, some of the rumors were in fact true.

Meanwhile, Microsoft has been scrambling to re-assure the new VB will still be VB in spirit if not in body. Based on feedback, the company changed its mind about the way boolean variables are represented. (For the record, it's back to good old fashioned -1 instead of 1 for vbTrue.) VB arrays have been tweaked several times. Recent builds of the tool have made the Microsoft compatibility layer more apparent. It wasn't clear, at first, whether old-fashioned VB functions like Right(), Left(), Mid() and even good old MsgBox() might not go away in the new version. (One well-placed off-the-record Microsoft source we talked to still wasn't sure.)

Rest assured, these old-fashioned functions are currently in place, and even if Microsoft would like to use newer .NET Framework classes to do exactly the same things, you can still find some of the flavor of traditional Visual Basic in the new .NET version.

VB.NET: The Spin from Redmond This doesn't mean that moving to the new VB.NET won't be an easy experience for many developers, but it does mean that you can and should take a breather and really see the big picture here. If you're a VB programmer, you might indeed still feel a little cheated. It's clear that Microsoft underestimated the loyalties of VB programmers for the look-and-feel of their favorite programming language. VB developers have been squeezed by Microsoft's full-court press in promoting .NET, which, after all, may eat into the company's commitment to the desktop and Windows. (If Steve Ballmer has his way, someday soon you will be licensing Microsoft Office remotely on a monthly basis, rather than running it on your desktop.)

Welcome to the world of Web services. Revolutions take no prisoners, and traditional VB stands for an older era of code-behind forms writing to databases on the client. Anyone could do it, and not everyone has the interest, skill, and-- let's admit it-- aptitude to write Web applications on the middle-tier, the stuff of Web services, a potentially hot new revenue model for Redmond.

And yet the new VB.NET is still destined to get its potentially most powerful upgrade yet. For the first time, for instance, there is no meaningful difference between developing in VB, or programming in the new C#, or in 20 other languages supported in the new .NET. "It's a great chance for every VB developer to be a Web developer," proclaims Mike Iem, Microsoft Visual Basic Product Manager. "You've really got the power to do anything. The VB guys now should feel now that there's nothing they can't take on."

Well said, of course. The future is in the Web, and the new VB takes us there. But do you really want to go there right now, in Fall 2001, when we'll presumably see VB.NET arrive?

Microsoft's gospel of empowerment for VB developers should be an easy sell because .NET Framework does have a lot of advantages, though so far it's been a bit hard to say why these are particular to VB. (The ecumenical spirit of .NET means that all programming languages are created pretty much equal. And why not? They all use exactly the same classes to talk to the underlying .NET platform.) The message is getting out, though, and the new VB.NET clearly is getting more popular than you might have heard from just tuning in to those rants in the VB newsgroups. Last time we checked, there were over 14,000 postings to news.devx.com, and while there were a good many programming questions, there were a bewildering number of flames/counterflames, too.

It's enough to give any busy developer a headache.

Most of us have to deal with real-world projects with real deadlines. Assuming that you won't defect and become a C# developer instead (and now seems to be a good time!), what's the best way to make sense of the new VB.NET? We did some investigating and looked at the current VB.NET beta, analyzed sample code, and interviewed a handful of working VB experts (most of whom build large, enterprise solutions). See Figure 1 below, Four Experts Rate VB.NET.

We asked some VB experts this question: On a scale of 1 to 10, with 10 being the easiest possible, how easy is it for programmers to move from VB 6 to the new VB.NET?

Figure 1: Experts Rate VB.NET Expert Rating Notable Quote Rocky Lhotka Co-author of VB.NET Programming with the Public Beta (ISBN: 1861004915) 7 "A qualified 7, qualified by that if you look at the PDC or Beta 1 build, that would not be the case. If you look at some of the more recent builds that their coming out, it's definitely a lot smoother." William Storage Chief Technical Architect, Breakaway Solutions (main office in Boston, MA) 7 "The languages are very similar. A whole lot of people have been led to believe that it's very difficult." "A small group of extremely vocal people have been talking about the departure from the spirit of Visual Basic that exists in .NET, and I don't buy it." Jay Schmelzer Partner/Engagement Director, Clarity Consulting (Chicago, IL) 5 or 6 "There's just a lot of new stuff that you need to become familiar with. There are a fair number of skills that carry over, but if you don't embrace the new stuff and get familiar with the new things, you're going to miss the boat a little bit." "I think unfortunately there will be a little carnage." Yasser Shohoud Independent Consultant/Trainer Web Services DevXPert (Washington, DC) 7 or 8 "I think it just comes naturally to a VB 6 developer. More consistent language features are an improvement. There's less to memorize. "Once you get it, you just do it."

Our sample was informal, but we tried to ask some tough questions. The answers for making the move to VB.NET are still evolving, just as Beta 2 of the product reaches developers this month (July 2001), but it's time to see how (and if) the new VB fits into your future development plans.

We were surprised at how many people told us that VB.NET is not right for every project, at least not right away. Strategically enough, Microsoft is very clearly not forcing developers to migrate every line of code to .NET in the next year. More exactly, it's up to you when to re-architect solutions to the brave new world of Web services and .NET. And you don't have to do it right away.

For starters, Microsoft has not announced an official support policy on support for Visual Basic 6, but it's clear that this is just a matter of time before this happens. On this front, Mike Iem, Microsoft VB Product Manager, gave us plenty of reassuring signals. "With 3.5 million developers and millions of lines of VB code, Microsoft will never leave its customers hanging. We're going to do the right thing for our customers and for their applications, and we don't want to pressure anybody [to upgrade]," he says.

Microsoft Visual Studio Lead Product Manager Dave Mendlen reiterated this position, "VB 4 was released in 1995 and we are in the middle of 2001, and we are still supporting that. In this situation, because of the shift in product direction with .NET, we think we'll have to go further with this. So just to give you a sense, we're still supporting six years back, and we'll probably even go further I suspect with .NET."

As one subject heading in a posting to news.devx.com (a hotbed of VB.NET activity over the last year) put it-- "COM RIP." Rumors of the demise of Microsoft's Component Object Model (COM), however, are definitely exaggerated. .NET components will supercede COM as state-of-the-art, and they will greatly simplify deployment with just an XCOPY operation. (No more COM registry settings, plus .NET components can exist side-by-side with one another, something unthinkable with COM.)

But interoperability between the two component standards is a big part of the plan for the immediate future in easing the transition into the world of .NET.

"You can just call a VB component, just like you can call a .NET component," Iem says. It's "pretty transparent and seamless and in fact we ourselves within the IDE, use some of this COM interop. Not every line of code in Visual Studio .NET is 100% managed." The familiar Microsoft motif of dogfooding its in-house technology is in evidence here as the company has demonstrated that COM and .NET can work together within the Visual Studio.NET IDE itself. (No, that's not the reason why Beta 1 was such a memory hog.) The bottom line is that if your shop has invested in business objects in COM or COM+, you can continue to use them in .NET, as well as calling .NET components from within older VB 6 code.

Further, while Iem views the change to VB.NET as an "opportunity" to re-design your legacy applications to go thin-client, this is neither mandatory nor a strongly argued best practice for now. "We're going to give [developers] some guidance on what we think is the right kind of application [to bring to VB.NET]. There are books out on that [to] help people decide what to interop, what to upgrade and what to write new. The key thing is they have choice," Iem says.

In the real world of enterprise development, Jay Schmelzer of Chicago-based Clarity Consulting has so far avoided advising his large clients from upgrading existing systems to .NET components right off the bat. "One of the things were seeing or almost recommending that people do is really look at leveraging the interoperatbility layers that are built-in the framework and the run-time," Schmelzer comments. "If you've been doing DCOM-based development for the last few years with VB5 and VB6, and using COM+ and those technologies, then our position for the most part [has] been don't bother trying to rewrite those applications yet."

As for performance between the old and the new, Schmelzer's team has been pleased. "The experience we've had so far with the interoperability layer has been very good. Sure there is a bit of a performance impact when you're looking at a .NET component talking to a COM component versus .NET to .NET, but it's not that bad. It's definitely livable," he says.

When it comes to SOAP (Simple Object Access Protocol), the foundation of Web services in .NET, Schmelzer also finds a small performance hit acceptable. "SOAP is a little bit slower than a pure DCOM," but the easing up of complexities with SOAP have so far been a win. This bodes well for the .NET platform, which relies heavily on this standard to get systems--and Web services--to talk to one another.

One important thing for using old code is to be able to run VB 6 and VB.NET together, even on the same system, as developers work with the old and new code. Bill Storage, Chief Technical Architect at Breakaway Solutions in Silicon Valley, notes that a practical advantage of VB.NET is that it can run side-by-side with the older VB 6 tool. "In previous versions of Visual Basic it was extremely difficult or impossible to run two versions on one computer at the same time. They collided with each other. That is definitely not the case with .NET; it will coexist with VB 6. So if you need to open up an old project to do a bug fix, unlike in the past, you can just open it up in VB and recompile and everything's okay."

Although you won't be able to target VB 6 code from VB.NET, you can choose to run the new IDE in a sort of backward compatibility mode, so it looks the same. Developers "can set up their profile to be VB 6 and they'll have the IDE just like they did in VB 6, so they don't have to worry about learning anything new," says Microsoft's Iem. "No 'where is the stove'? Everything's going to be right where it was in VB 6."

See Figure 2 below, screenshot of VB.NET in VB 6 mode.

A frequent defender of the advantages of VB.NET in newsgroups, Storage works on enterprise software, typically "150,000 lines of code on 4 tiers" he says. He also does training with programmers coming to Visual Basic and finds the new language is cleaner and just more logical, especially with enforcing data types more strongly. His explanation for all the online trouble within the VB.NET community is that a noisy few generated the most static.

"I think that a small group of extremely vocal people have been talking about the departure from the spirit of Visual Basic that exists in .NET, and I don't buy it. I think those folks have a vested interest in perfectly backwardly compatible code, and they do not at all represent standard corporate users," he said.

We were surprised that apart from the Microsoft 'vision' for bringing VB developers along for the ride with .NET, it's quite possible that the most important features of the new VB.NET are its classes, like the ADO.NET objects for working with databases. "The number one advantage that I see .NET bringing is ADO.NET. Like the vast majority of programmers these days, I write apps that have something to do with a database. There's a radically different ADO, and it's vastly superior," says Storage. See Figure 3 below for ADO.NET's new object model. Improved support for disconnected recordsets and XML help make this new standard a winning enhancement to .NET.

The other feature that Storage finds important is inheritance, which turns out to be a real productivity boost, in an unexpectedly pragmatic way. "There were a lot of us who were saying in past versions of Visual Basic that inheritance is fun but it's basically enough rope for less than very experienced programmers to hang themselves," he explains.

"Well as soon as you start working with the .NET beta trying to do some database work, you realize here's an aspect of inheritance that I've never even thought about before because I'm always thinking about inheritance in the traditional 'Derive a Dog from an Animal' sense. The ability to have a recordset called Employee and then when you're writing your code you type 'Employee' and the dot (.), and then IntelliSense pops up with a LastName field, it's really profound, if for no other reason than the productivity enhancement in the code-writing process."

So learning the ins and outs of inheritance might well be a key process for the new VB.NET user, especially having been denied true inheritance until this latest version. Common gothchas include forcing classes to inherit from one another even though they don't share a subclass (or IS-A relationship). We've all done that at one time or another, making Propeller derive from Airplane. Used correctly, though, inheritance appears to hold even more promise in new Visual Basic, since besides ADO.NET recordsets, you can use 'visual inheritance' to create re-usable forms easily (both on or off the Web).

Microsoft's David Mendlin observes, "One of the interesting things about [the older] VB is that you saw a lot of black boxes, the form, for example. You couldn't actually see how a form was constructed. Now we can actually unroll the code and see the way the form's constructed, you can change it if you don't like it." Because .NET builds forms using actual code statements visible to the programmer (not through behind-the-scenes VB script or even separate Windows resources), developers can see what's going on and control this process better within the new VB.NET.

Besides new ADO classes and inheritance generally, programmers need to explore what the .NET framework can give them, while also realizing that this rich, Java-like class library really does have some level of backward compatibility built-in. For the first time, Visual Basic developers have a rich class library at their disposal.

Like many new rich and complex technologies, this can be both blessing and curse. Yasser Shohoud, an independent consultant based in Washington, DC points out that in previous editions of Visual Basic, there was no real class library. Having a full-fledged class library "is really new for VB developers," argues Shohoud. "They're used to getting a COM component, adding a reference to it, and every COM component works in its own way." While previous versions of VB featured a loose collection of COM-based ActiveX 'widgets,' the new .NET adds classes that relate to each other, using inheritance and interfaces. Often classes will need to be used together to do real work, something that may not come easy even to experienced VB developers.

The trick to the .NET Framework is that by and large, it looks like Java code to us (and to a lot of people). See our "Java vs. C#" tutorial story. The API's looks like Java and feel like Java. At first glance, the panic experienced by Visual Basic stalwarts occurred when they came "up close" to early sample code, and Microsoft touting the advantages of .NET classes for productivity, at expense of the 'look-and-feel' and the traditional style of their favorite programming language.

Rocky Lhotka, author of several books on VB programming including a new title on VB.NET, describes it like this. "VB.NET is most definitely Visual Basic, but were you to do what actually a lot of the Microsoft examples do, and just use the Framework rather than using the normal VB functions to do things like Left() and Right() and so forth, that really is Visual Fred," he says. "A VB developer looks at code like that and it doesn't look like VB."

The answer is to dig into the Microsoft.VisualBasic namespace, a group of functions that VB programmers have grown to trust over the years. "The Microsoft.VisualBasic namespace incorporates all of the functions and methods that people like me at least view as being part of Visual Basic, even though technically they're not keywords in the language," Lhotka observes. "If you don't have MsgBox(), if you don't have Mid(), Left(), and Right(), and there's a whole host of functions that are not keywords, if you don't have them, you aren't really doing Visual Basic." See Figure 4 below for a listing of sample compatibility layer VB functions.

Figure 4: Backward Compatibility With VB 6 in VB.NET MsgBox Right Trim LTrim RTrim Round Rnd Date Time Oct Hex Str Chr Environ Space Error CurDir Left Mid LCase UCase Command

The apparent disappearance of these legacy functions has to be one of the biggest reasons for setting off a tsunami of protest within the VB community. Microsoft did not exactly advertise the existence of this compatibility layer, choosing instead to beat the drum for .NET. But these functions are indeed in the language and can be used by anyone seeking more familiar terrain--and a well-known coding style--when approaching VB.NET for the very first time. "There's no reason not to" use the compatibility layer, says Bill Storage, and he notes that except in a few rare cases, compatibility layer calls are just as efficient as their .NET counterparts, but with a friendly, familiar syntax.

It's also possible to see that developers armed with new .NET Windows Forms classes (the section of .NET that deals with traditional desktop clients) and the new ADO can turn back the clock a bit with new way to write old-fashioned, 'traditional' VB style client-side applications. "There's a lot of misperception out there too that because VB.NET is finally object-oriented, one will have to do object-oriented programming," comments Lhotka. "And that's totally false. It's perfectly possible to do what I describe as VB 3-style programming, where you just write code behind the form, and talk directly to a dataset, and don't really interact with objects or create objects at all."

"A lot of developers think that when we did VB.NET, we just totally forgot about building rich Windows applications," adds Microsoft's David Mendlen. "With visual inheritance, in-place menu editing, and a laundry list of features in the Windows space, it's probably the best upgrade for Windows developers, even if you decide not to do Web stuff."

Of course, there are many language features that don't make the leap from the old VB 6 to the new VB.NET. By publishing another 'laundry list' of language features that would be discontinued (like GOSUB, the Variant keyword, and WEND), Microsoft generated a lot of discussion, to the say the least. That, and the combination of stressing .NET Framework code went a long way to make VB.NET look like a more severe upgrade than it probably really is destined to be in its final release. (Of course, the damage control resulting from the cyber-protest has no doubt influenced the final version of VB as well.)

Another reason for trouble is that Microsoft has consistently adopted a tone that "a complete re-write of VB is good for you," something that didn't sit well with developers who loved the language despite its oddities and imperfections. (Many VB developers had a pet peeve or two about the language, which they would like to see improved. VB fostered the amateur language architect in all of us.) All of a sudden, developers were being told that their favorite programming language was almost entirely bad, rife with constructs that led to sloppy code.

Basically, Microsoft has argued that it's necessary to clean up the old VB to fit into the underpinnings of the new .NET with its Common Language Runtime (CLR) (see our related .NET story). Conformance to the CLR is one reason why data types have been changed in VB, much to the chagrin of some programmers. (No more Variants for instance, and the range of common numerical data types has been changed too.) This common language 'core' permits some 21 languages to interoperate. (Microsoft has recently submitted the CLR to ECMA to move it forward as a standard, thus promoting a wide adoption by third party vendors who can write languages that work with .NET.)

But in tightening up the language, there's a tone that sometimes rankles a loyal VB community as once again VB was apparently sacrificed on the altar of .NET.

"VB developers got a bad reputation over the years because they didn't dimension their variables, they were doing unsafe casts, and were having these unexpected errors," says Microsoft's Iem. "A lot of the reason for that was because we let VB developers write code that just didn't work, and that had sporadic bugs. Now with the typesafe system and the option Strict on by default, VB developers initially are going to have a little pain."

But in the long run, according to this argument, VB programmers will be more productive and write higher-quality production-level code, which wasn't always possible with older versions and implicit programming practices.

So it's a bit of "take your medicine because it's good you." This ethos has no doubt made VB.NET figuratively hard to swallow for some developers, who have concentrated on the small things in the language that are disappearing, in the interest of tighter, more robust code for .NET.

Migration tool Panic Another factor in the slight tension between Microsoft and the VB community has to be the state of its VB.NET migration tool, which takes older VB 6 code and generates the VB.NET equivalent. Once again, Microsoft took a bit of a hit from an earlier release that didn't work as well as it probably should have. "The beta one version that a lot of people have seen is not the final version," assures Iem. "They just ran their application in the wizard, it didn't work at all, and they just panicked. With the arrival of Beta 2, he says. "It's a lot more done, it's still not going to be final, but it's a lot closer." See Figure 5 for Microsoft's complete list of suggestions for preparing your VB code to work with the migration wizard.

The following suggestions are based on a Microsoft white paper on preparing your VB 6 code for VB.NET. If you make these changes to your VB 6, the migration wizard will do a better job of converting your code for use with VB.NET.

Source: Microsoft Developers Network (MSDN) Declare all your variables.

	WRONG (VB 6)
	RIGHT (VB.NET)



			
				Total = OrderTotal + SubTotal
				Dim Total as Double

						Dim OrderTotal as Double

						Dim SubTotal as Double

						Total = OrderTotal + SubTotal

			
		

Instead of the Variant data type, use Object.

	WRONG
	RIGHT



			
				Dim myObject as Variant
				Dim myObject as Object

			
		

Instead of the Integer data type, use Short.

	WRONG
	RIGHT



			
				Dim Count as Integer
				Dim Count as Short

			
		

Use early-binding, not late-binding, when working with objects.

	WRONG
	RIGHT



			
				Dim MyObj as Object
set MyObj = me.MyListBox
Obj.AddItem "Red"
MyObj.AddItem "While"
MyObj.AddItem "Blue"
				MyListBox.AddItem "Red"
MyListBox.AddItem "White"
MyListBox.AddItem "Blue"

			
		

Use Date for storing dates, not Double as in VB 6.

	WRONG
	RIGHT



			
				Dim StartDate as Double
				Dim StartDate as Date
			
		

Specify all properties for components and objects--don't use default properties as they aren't supported in VB.NET and will confuse the upgrade wizard.

	WRONG
	RIGHT



			
				MyLabel = "New Caption"
				MyLabel.Caption = "New Caption"
			
		

The same tip holds for objects passed as parameters:

	WRONG
	RIGHT



			
				DisplayACaption MyLabel 
				DisplayACaption MyLabel.Caption
			
		

In previous versions of VB, if a Null value was passed to some functions, they were guaranteed to return Null without generating errors. (This is called "null propagation".) It's not supported in VB.NET.

	WRONG
	RIGHT



			
				Dim s1 as String
s = Null + "Hello"
' s is Null after this call
				' Can't add Null parameters
s = "Hello"
			
		

Use Zero Bound Arrays. VB.NET Arrays always start at 0 (just like C/C++/Java!).

	WRONG
	RIGHT



			
				Dim intArray(1 To 10) As Integer
Dim strArray(-5 To 5) As String
Dim moneyArray(10) As Double

Dim strArray(-5 To 5) As String
Dim moneyArray(10) As Double
' (Note this depends on Option
'   Base 0 or 1 setting, which
'   is no longer supported!)
				Dim intArray(10) As Integer
Dim strArray(11) As String
Dim moneyArray(10) As Double

' All arrays are zero bound!
			
		

Use Visual Basic constants rather than hard-coded numbers in your code.

	WRONG
	RIGHT



			
				If answer = -1 Then
   ' It's true
End If
MsgBox "Error", 0
				If answer = True Then
   ' It's true
End If
MsgBox "Error", vbOKOnly
			
		

Get rid of fixed-length strings as they are no longer supported in VB.NET.

	WRONG
	RIGHT



			
				Dim FirstName As String * 30
Dim LastName As String * 40
				Dim FirstName As String
Dim LastName As String
			
		

Remove the following keywords from all your old VB 6 code because they are no longer supported in VB.NET:

			
				Def<type>
e.g., DefBool, DefType etc.

Computed Goto/GoSub
	On v GoTo 1000, 2000, 3000

GoSub / Return
Option Base 0 (or 1)
				VarPtr

ObjPtr

StrPtr

LSet
			
		

Windows API calls are still supported, but be aware that the data types may change (Integer to Short, etc.) in their prototypes: For preparation for the VB.NET Windows Forms classes (instead of VB 6 Forms) for client-side user interfaces, remember that:  The OLE, Shape, and Line controls are no longer supported.  Don't use Form methods like Circle, CLS, PSet, Line, and Point. .NET offers new calls to do graphics. (You will need to re-write this code yourself.)  You can no longer print windows forms with Form.PrintForm.  You can no longer disable a Timer control by setting its Interval to 0. Instead, set its Enabled property to False.

	WRONG
	RIGHT



			
				' Stop this timer
myTimer.Interval = 0
				' Stop this timer
myTimer.Enabled = False
			
		

Different .NET classes are used for such features as drag-and-drop programming, clipboard handling, and DDE. If you're using features like these, you have more work to do.

(Remember, these are suggestions for getting VB 6 code ready for VB.NET using the migration wizard. This tool will completely re-write much of your code automatically.)

But recent reassurances aside, with a VB community of some 3.5 million developers, the hard fact is that objects are not for everybody. There is a core lower-end group of VB developers for whom the magic of object-oriented design holds no pull.

"I'm very much an optimist," says Jay Schmelzer, "but I think unfortunately there will be a little carnage. You will have some people that are doing development today that will probably not pick this up very quickly."

And without a compelling reason to upgrade to Web-based systems and Web services, there's little reason for a dyed-in-the-wool 'traditional' VB programmer to make the move to VB.NET anyway, even if it is possible to create thick, rich fat clients in the new version. "I have a hard time imagining VB developers writing desktop applications that maybe use Access as a database--a classical VB desktop application, moving to .NET. I couldn't sell them on that," Yasser Shohoud insists.

Fundamentally, the reason to switch to VB.NET is still tied up in the advantages (and, to be fair, possible disadvantages) of the new .NET platform. As Rocky Lhotka says, "When you look at it, you've got to remember that you're generally keeping the same language. You still essentially have Visual Basic [with] VB.NET, but you're changing platforms. You're changing from Windows COM into .NET, and that by itself has a substantial impact. You've got to go in with your eyes open and say, well, they're similar platforms, but they're certainly not the same."

And finally, the best advice is to remember that .NET is still new technology, which really is still evolving. Even allowing that Microsoft was not very sensitive about preserving the flavor of VB in early versions, samples, and documentation, it's clear a good deal of the initial furor was due to (over) reacting to incomplete betas.

"The first thing that I've cautioned people on is that we are working with the beta, and it is changing," advises Lhotka. "I think that we've already seen some of this where people will jump into the PDC or Beta 1 build and will assume that's it. They panic. It's important to keep a level of perspective, above all else, that things are changing and are in general improving. It's just critical to keep a level head."

For working VB developers and managers who want to grow with their favorite tool and technology, there already has been some real turbulence on the journey to VB.NET, but it's clear that Microsoft will continue to work to appease a loyal community of developers as much as possible while pursuing its goals for .NET. As it has in the past with VB, it has been responsive to the concerns raised by people who really care about preserving the spirit of VB. After all, the move to VB 3 and VB 4 was pretty tough as well.

"That (to VB3 and VB4) was a big shift, and we got our customers through it, and we're going to get them through this as well," observes Iem. "This is a big shift," but he doesn't believe it is a bigger one in the move to VB.NET. "It's tough for some people, not tough for others. I think it all depends on what you were doing. For some VB guys, the shift to .NET is no shift at all."

Though no one can expect that Microsoft will tone down its .NET platform push (which is so vital for its new long-term vision of computing) for a much-loved language, 3.5 million voices can't be ignored. So expect the folks at Redmond to do even more to make sure that the new VB measures up to the expectations of this loyal, vocal and excitable worldwide developer community.

Copyright © 2004 Ziff Davis Media Inc. All Rights Reserved. Originally appearing in ExtremeTech.