am the host of ".NET Rocks!", an Internet audio talk show for .NET developers online at www.dotnetrocks.com
. My co-host Richard Campbell and I interview the movers and shakers in the .NET community. We have nearly 200 shows archived online, and we publish a new show every Tuesday morning. For more history of the show check out the May/June 2004 issue of CoDe Magazine, in which the first column appeared.
In Show #184 I talked to Jon Rauschenberger about his secrets for moving VB6 applications to .NET using a toolkit that he helped the Microsoft VB team develop.
Carl Franklin: So Jon, what are you working on and thinking about these days?
Jon Rauschenberger: Well, I am doing a bunch of things. [In] my role at Clarity I am kind of charged with thinking about technology and where should we invest in technologies to help our customers. And I am also running a couple of our projects, so I actually get to apply the stuff that we're thinking about and seeing how it works in real world. One of the most interesting things we just wrapped up is a project for Microsoft with the interoperability layer between VB 6.0 and VB.NET that we've been working on with them for about the last two and half months.
Carl Franklin: Yeah, this is something that you don't hear about a lot and that a lot of people desperately need to know how to do. Maybe not a lot of people, but there is really a good handful of people who are depending on this old legacy code. And the Interop story between VB 6.0 has never particularly been good if you are in VB 6.0 trying to access VB.NET.
Jon Rauschenberger: Yeah, and that's what really what drove this effort we did with Microsoft. It was just looking at not only our customers, but all the companies out there that are still running big chunks of their business on VB 6.0 apps that work fine. They're doing what they're supposed to dothey're enhancing them, fixing them, but those apps are running their business and it is a challenge to move them over, and we wanted to see if we [could] come up with a way to help out with some of that migration.
Carl Franklin: I am curious as to how you did it. I remember trying to expose some things to VB 6.0 through VB.NET and using VB 6.0 as the host and going the other way, it's pretty simple. You've got an
ActiveX DLL and you get the IntelliSense and all that, and you have nice features on the .NET side, but going back the other way, you don't have IntelliSense. And
if you want to pass a dataset to VB 6.0 for example, oh my God! That's a can of worms right there! I found I had to make type libraries for all of these assemblies in the .NET Framework and it just hit me all of sudden, "How come there isn't just a great big type library for the .NET Framework, for everything?"
Jon Rauschenberger: Sure. So, the Interop story has always been pretty interesting for Microsoft. There [have] been some good points and there [have] been bad points, and you touched on the bunch of them. I mean, some of the Interop stuff does just kind of work nicely. You slap a COM interface on a nice simple VB.NET DLL, it references from VB 6.0, and as long as you're not doing anything along the lines of passing datasets around, it works fairly well, it's pretty easy. There were a couple of places though, where we just saw our customers struggling, us struggling, when we would try to work with it. You touched on one. Datasets and recordsets interoperability is pretty much non-existent and you have to hand-code it. And the other big one though, we felt like it was pretty broadly applicable, was, "How do I take a visual thing, let's say, and not try to tie it to a technology, but how do I take a visual piece of functionality that I have written in VB 6.0 or alternatively that I have written in VB.NET and make those two Interop nicely so that I can have one application, where one form is a VB 6.0 form and the other form is a VB.NET form, and let me, as a developer pick and choose, when if I am going to at all, when am I going to migrate a form over to the VB.NET or when am I going to write something new in VB.NET?" And if you ever try it, it's interesting, I spoke at TechEd and I asked this question: "How many people have run a form based on VB 6.0 through the conversion wizard?" Pretty much everybody in the room, about 150 people, raised their hands and [then} I asked, "How many of you were delighted with the results you got?" One guy left his hand up. I don't what kind of luck he had, but he was happy with what he got.
Carl Franklin: He probably works at Microsoft.
Jon Rauschenberger: It could be, yes. He did have a blue shirt on, may be, but
Richard Campbell: Now, I find it interesting that you're talking about forms because when you first talked about companies still running VB 6.0 code, I am thinking COM DLLs that they're not ready to give up on yet. They're too complicated. They got too much code in them. You're actually talking about forms and clients, they're written in VB 6.0. They're not ready to give up that yet either.
Jon Rauschenberger: Yeah, it is both. I mean, there certainly is a ton of code out there that's better than COM DLLs written in VB 6.0 that people need to carry forward and continue using. We looked at that, though you know, with the exception of some data type problemsthere are some workable solutions for that.
Richard Campbell: So, the Interop story is not that bad.
Jon Rauschenberger: It's not that bad until you get some of the data-type problemsrecordsets and datasets being the biggest one. There are a handful of others but for the most part, if you wrote your COM DLL in VB6, .NET is going to be able to consume it fine.
Carl Franklin: Yeah, that's not the issue.
Jon Rauschenberger: If you flip it aroundyou write something in .NET, you are exposing, you know, a System.Drawing.Point or some other data type that VB6 has no clue what to do with, then you can get into problems. But, you know, the other way around we've got plenty of customers that have built VB .NET or ASP.NET apps that use their old VB6 COM DLLs without having to convert them over. Alternately, when you talk about the code conversion story, honestly it's not that bad if you run a non-Visual DLL through. And with the recordset disclaimer; but if you have got a COM DLL that you wrote in VB.NET that has no UI elements to it, you run it through the conversion tool, and you are 95 percent of the way there.