There exists in the world millions of Visual Basic 6 developers and enormous amount of VB6 code. What does the landscape look like for this tremendous pool of legacy code and talent? Scott Swigart recently sat down with Jay Roxe, Microsoft Product Manager for Visual Basic, to find out.
SS: Jay, thanks for taking the time to chat. I know that you've been focused a lot on VB6 to VB.NET migration, and the first question I have is, could you define that for me? I know what "migration" means to me, but when you use that term, what exactly are you talking about?
JR: The first thing that I focus on with VB6 developers, who are looking to upgrade to VB2003 or VB2005, is where they can take advantage of their existing skills. We find that VB6 developers, particularly when they try VB2005, find that it feels very familiar.
When Microsoft initially talked about the .NET Framework, we focused on Web services, and XML, and a lot of things that are a very important part of what we do with the .NET Framework, but we didn't spend as much time talking about how we made it easier to build Windows, Web, Office, and mobile applications. So, when VB6 developers upgrade their skills, they find that a lot those skills still apply, but they have a broader and more scalable set of development possibilities than they had with VB6. So the first thing I encourage a VB6 developer to do when coming forward is to write a project entirely in VB.NET, and just get a feel for the language and the .NET Framework.
We also know there are a lot of VB6 developers that have existing code that they want to bring forward, and there are a number of different things we're doing to help on that front. We introduced a Web site called VBRUN, which is the VB6 resource center. It has some of the best of the best VB6 content. VBRUN also has a section called VB Fusion , which, Scott, I know you're familiar with.
SS: You could say that... [Editor's note: Scott Swigart has authored numerous articles for the VB Fusion site.]
JR: VB Fusion shows how to use VB.NET and VB6 together. And finally, there's a section on VBRUN about getting the most out of VB.NET.
The reason I bring up VBRUN is that the VB Fusion section talks a lot about how developers can use their existing code through Interop, which means they don't need to do a complete upgrade. They can gradually add VB2005 components to an existing VB6 application. They can take a slower upgrade path, upgrading various pieces of the application where it makes sense. And they can access existing pieces of the application through Interop.
And finally, we know there are developers who want to go whole-hog on the process and upgrade an entire application. We have some information from the Patterns and Practices group that enables developers to get prescriptive guidance on bringing an application forward from VB6 to VB .NET 2003 or VB20054.
SS: When you're talking to customers, what are some of the reasons that they give for even wanting to do a complete upgrade to VB.NET, versus just keeping their code in VB6?
JR: They motivations for doing an upgrade are pretty varied. Some of the motivations just relate to the lifecycle of any application. The application has reached a point where the code has grown beyond its original scope, and it's time to rewrite the application anyways, and it just makes sense to transition to the latest development platform at the same time. We also know there are developers that really feel they want to take advantage, throughout the application, of the fact that the .NET Framework offers tremendously more functionality than the VB6 runtime. There are developers who say, "I want an Office component. I want a mobile component. I have a Smart Client. I want a Web interface." We're seeing customers who are putting together those types of applications and leveraging the fact that you really can do more with VB.NET.
Finally, we're seeing some customers who are upgrading because they're concerned about the support lifecycle for VB6, and I'd like to spend some time before we finish to clarify a couple of misconceptions around support as it exists right now.
SS: I think the VB6 lifecycle is an important point, so I'll make sure we get back to that. But first, from the customers who've done a migration of a substantial application, what would they list as some of the main benefits of the migration?
JR: We're seeing a number of our largest customers who are really starting this process now. I do presentations at our executive briefing center, and there I've probably presented to 15 Fortune 500 companies over the last two years that are starting this process now with their applications. We also do labs here on campus where we work with some customers on doing complete migrations. Some people are doing it because they want to put an ASP.NET interface on their existing business logic. Some people are finding that they can take advantage of the new deployment capabilities in VB2005, to easily deploy applications, and ensure that the users are always running the latest version. We're also seeing, particularly for some of our Web customers, that when they took a VB6/ASP application, and moved it to a VB.NET/ASP.NET application, it was 300 percent more scalable, and they got 200 percent more throughput from the application.
SS: One of the things you mentioned in there was a better deployment and management story, and I'm assuming that what you're referring to is the technology that Microsoft calls ClickOnce in Visual Studio 2005. From the perspective of a VB6 developer, why is ClickOnce something they might care about?
JR: ClickOnce is a technology that I'm very excited about, because in VB6 developers were very familiar with the concept of "DLL Hell", where deploying one application to a machine could break already existing applications on that machine. You'd register a new version of a COM control, and it could break applications that were using the previous version of that control. With the .NET Framework 1.0, and VS .NET 2002, we solved this problem and went to a side-by-side deployment model, where deploying an application wouldn't impact any other applications on the machine. That still left us with the questions of, "How do you get the application to the machine? How do you ensure that the prerequisites are on the machine? And, how do you get versioning for the application?"
When you ClickOnce deploy an application, and the user installs that application, the first thing that runs is a bootstrapper that makes sure the necessary prerequisites, like the .NET Framework 2.0, and optional prerequisites, like SQL Server Express Edition, the Windows Installer, and any one of a number of other components, are available on the local machine. ClickOnce will install them if they're not already there. It will then install the application itself, and the application installs to a location under "Documents and Settings" so that you can install the application as a normal user. You don't have to have admin rights to install a ClickOnce deployed application. You might need admin rights to install some of these prerequisites, but not the application itself.
Optionally, in a ClickOnce application, you can set up version checking. After a certain specified interval, or whenever the application starts up, it checks to see if there's a new version of the application available. If there is, it can download an install that application. The developer gets the benefits of having all the prerequisites deployed, automatically getting the application installed by a normal user, and getting versioning built-in to insure that your users are always running the correct version of your application.
It's going to be tremendous saving for companies that have home-grown ways of versioning department level applications, and it will integrate with things like SMS or MOM that are more enterprise grade solutions.
SS: One of the things we're seeing across the software industry is applications that are much smarter about knowing when there's a new version available. One of the things that excites me about ClickOnce is that it just makes building those kinds of applications a lot easier.
JR: It's almost a default. Such that all you have to do is say, "Publish this application," and you get a set of intelligent default behaviors.
SS: Another thing that I think is really interesting, especially for VB6 developers, is the concept of RegFree COM with ClickOnce.
JR: This is a really great feature. This means that you can deploy a COM component with your application, without having to register the COM component. This also means that you can have multiple versions of the same COM component installed side-by-side, and they don't conflict with each other. You can use ClickOnce deployment to deploy a .NET application that uses COM objects, and the COM objects are deployed with the app, in this RegFree manner.
What's actually happening is that we're exposing a Windows XP and Windows Server 2003 feature that allows for isolated deployment of COM components. By using a manifest file, the loader can look for a local instance of the COM dll before it goes to the registry to find it. This is an operating system feature, but because there has not been tool support for this previously, this is going to come as a tremendous advance for Visual Studio users.
SS: By tool support you mean that as a developer, you don't have to worry about creating that manifest file? If your app depends on COM components, and you publish your app, then all that RegFree COM stuff just happens for you?
JR: That's correct.
SS: Earlier, you mentioned wanting to address misconceptions about the VB6 lifecycle, and I know there's been a lot of uproar about this topic. What is the status of VB6, how is this being perceived by customers, and what does this mean in practical terms?
JR: Microsoft had always talked about VB6 as though it were a single thing, as in, "I installed Visual Basic." In reality, there are two parts. There's the Visual Basic design environment, and there's the Visual Basic runtime. We never really spoke of those separately, but they are separate things.
What happened on March 31st of this year (2005), is that the VB6 design environment moved from mainstream support to extended support. It's a seven-year old product that's had six service packs. It's pretty stable. It's pretty well known what the behaviors are going to be. It also means that if you have the two warranty cards that came in the box with VB6, those warranty cards have expired, seven years later. But, support is still available for the product. MSDN subscribers get a certain number of support incidents, fee-based support is available, and support is available through a very, very robust community of VB6 developers. The extended support lifecycle for the development tool continues through March of 2008. And then there are custom support contracts available through 2012.
Now, when it comes to the VB6 runtime, it is scheduled to ship as part of Windows Vista, which means that it will be covered under Vista's support lifecycle. This is five years of mainstream support, plus five years of extended support, from the date that Windows Vista ships. So the runtime itself will continue to be supported for quite some time yet.
I think the differentiation between the runtime, and the design environment, is a place where there's been some confusion in the industry. The important thing is, VB6 applications that today run on Windows XP or Windows Server 2003, should run on Windows Vista. There are always changes with the operating system from one version to another, for example, there were changes between Windows 2000 and Windows XP in how certain controls behave. However, we are running all of the acceptance tests for VB6 on Windows Vista, and they all pass.
SS: I know that one of the concerns has been, "My app isn't going to run on Vista." It sounds like what you're saying, pretty clearly, is that going to Vista isn't any more of an issue than going from Windows 2000 to Windows XP. It's a new operating system, and there's always the potential for incompatibilities, but Microsoft isn't doing anything to break VB6, or doing anything knowingly keep VB6 from running. In fact, by shipping the VB runtime as part of the operating system, you're hoping that most VB6 apps will keep running without a problem.
JR: And we're testing to insure that most VB6 apps will keep running without any problem.
SS: Getting back to the migration issue, what are some of the key obstacles that customers face when they get ready to take their development team, and their applications, and do a significant migration.
JR: I'll go back to one of the things we talked about earlier, which is that developers should be familiar with VB.NET programming first, before they perform a migration. When I work with customers in migration labs, the two overwhelming factors that determine the success of the migration are: how well structured is the code to begin with, and how well do the developers know .NET Framework programming.
How well structured the code is, is something that's honestly in the "Too Late Now" category. If it's not well structured already, you're not likely to make it well structured before doing the migration. But, making sure the developers are familiar with .NET Framework programming, and Visual Basic 2005 programming, is something we see people putting good processes in place for. We see organizations that have formal mentorship programs, where they train a few of their developers, and then those developers are responsible for training other developers. That's turned out to be very effective in sometimes getting developers to realize that instead of spending hours trying to get some function to work, the better solution is to rip that function out and instead rely on something that's already in the .NET Framework.
SS: In other words, taking a team that only knows VB6, and having them migrate one of their mission critical apps, and trying to use the migration process as a way to learn VB.NET, isn't what you would consider a recipe for success?
JR: That is not how I recommend people approach the process. There are also a number of detailed technical issues that people run into, such as how to Interop with a certain control, or how to use COM+ Services, just as two examples. There are two references that I refer people to. The first is the Patterns and Practices book. This is our most up-to-date reference, and will give detailed technical advice on how to approach those questions.
SS: And that's just a free, public resource, right?
JR: It's a free resource, and it comes with a tool that I think will be very interesting, which is a migration cost estimation tool. It's a derivative of the migration wizard, and will analyze your code, looking at things like the number of lines of code, the complexity of the code, things you're using that we know will be difficult to migrate using the wizard, and it will estimate the time required to migrate. You can even dial certain things down if, for example, you know that for a certain third-party control, you have a really simple solution for how you're going to deal with that.
The second resource is up on VBRUN, which is a Microsoft Press book on migrating applications from VB6 to VB.NET The book dates from the 2002 release of Visual Studio .NET, and a few things have changed for 2005, but the practices that it recommends are still valid, and still valuable to developers.
SS: That brings up another thing that I wanted to talk about. I know that Microsoft has a lot of resources here and there to assist with migration. What are the resources that people have available when they sit down to migrate code?
JR: This is quite a lengthy list. We have the Visual Basic Developer Center. We have VBRUN, which is the Visual Basic 6 resource center, which helps developers not only with the challenges they're facing in VB6, but also information on how they can move forward. Off of that center, there are also a number of freely available books, whitepapers, and other content. Another part of VBRUN is the featured partners section. We're working with a number of our training partners to provide sample chapters, sample applications, sample videos, on how developers can upgrade their skills from VB6 to VB2005. We have an area called VB@TheMovies which is 101 small videos that show how developers can do certain things in Visual Studio .NET. We have a series of web casts that will be available world-wide on this topic. We also have local events this year. This is a corporate initiative and we're very interested in helping people succeed with migration.
Developers who are interested in this topic should check in with VBRUN, and that's msdn.microsoft.com/vbrun. We'll be posting links to this, and other information on migration, up on that site.
SS: It also seems that Microsoft released something a while back called the "upgrade advisor"?
JR: It's the VB6 Code Advisor, and it's something we reference from the Patterns and Practices book. It runs over your VB6 code, and spots certain things. For example, if you haven't strongly typed a variable. We know that's going to cause problems for the migration wizard, and this gives you the opportunity to fix things in your VB6 code. So you can, for example, strongly type your VB6 variables (which is 50 percent of the issues that we see in the migration wizard), and then use the migration wizard, and the migration will go much more smoothly. There's detailed documentation for that on-line, and again, it's covered in the Patterns and Practices guide.
SS: In other words, doing a little work on your code before you feed it in to the migration wizard might result in a lot less work for the code that comes out of the migration wizard.
JR: Yes, exactly that. And when things come out of the migration wizard, sometimes users see large amounts of errors or warnings. For example, it might say that there are 1000 errors and warnings. Some developers see that and get very concerned about their application. What we see is that the vast majority of those take almost no time to fix. I'd encourage them to take a close look at what will be required to fix those, before getting overly concerned.
SS: And that gets back to the notion of being experienced with VB.NET before you do an upgrade, because then you can look at those errors and say, "Oh, that's easy to fix." But, if you are inexperienced with VB.NET, you might see the same error and not have any idea what to do to solve it.
JR: Exactly.
SS: One of the things I hear people say, and this is a statement that I've been hearing for five years now, is, "If you're going to go from VB6 to .NET, you might as well just go all the way to C#." How would you respond to that?
JR: I'm not sure where the idea of going "all the way" to C# comes from, because C# is not more of a .NET language than Visual Basic, nor vice-versa. The focus in 2005, on both languages, is making sure that both languages have the full power of the .NET Framework and runtime. They both got advances like generics. They both got edit and continue. But, the languages are also evolving their own distinct flavors. The Visual Basic team, for example, invested in the My namespace, which provides a speed dial into the .NET Framework, and provides dynamic programmatic access to things like Web services, forms, resources, and settings, some of which are things that are needed in every application.
Our research shows us that there are about equal numbers of VB.NET and C# developers out in the world. And for VB6 developers coming forward, it's an easier, smoother, migration path to VB2005, because they'll find that they can re-use a lot of their skills.
A lot of the perception comes from the fact that when Microsoft released the .NET Framework 1.0, C# was the new language. It naturally got a lot of buzz. Because it got that buzz, people got the impression that C# was the language of .NET, or that Microsoft was more committed to C# than any other language. Having worked with both development teams, I can simply tell you, that's not true. We are very committed to both languages, and will continue to innovate in both of them. This is something that's been echoed by all levels of our management, including Somasegar, who's the vice president of the developer division, who said in one of his blog entries how proud he is of some of the advances that have been made in Visual Basic, and how we're going to continue that trend.
SS: Jay, thanks for taking the time to chat.
JR: Thank you.
Scott Swigart is consultant specializing in convergence of current and emerging technologies. Scott can be contacted at [email protected].
