Login | Register   
Twitter
RSS Feed
Download our iPhone app
TODAY'S HEADLINES  |   ARTICLE ARCHIVE  |   FORUMS  |   TIP BANK
Browse DevX
Sign up for e-mail newsletters from DevX


advertisement
 

Heard on .NET Rocks! Moving VB6 Applications to .NET : Page 2

Carl Franklin interviews Jon Rauschenberger to explore the process of moving VB6 applications to .NET.


advertisement
.NET Rocks! (continued)
Carl Franklin: So as long as you use the primitive data types, I mean, if you use convertible data types, "blittable" I guess you call them. Right? Jon Rauschenberger: Yes. You know, the data type restrictions are always there. You know, there is something I think Microsoft can do to make it easier but at least you had a path, you had resources out there to say, "If you are using these data types here's some things you can do." You know, there was some guidance. Where we really saw a void was, I got a form that I wrote in VB .NET, "How the hell can I consume that or use that from my VB6 App?" and really there was just a void of guidance to us—just kind of nothing. So … we had a customer who had a large VB6 app, had a hundred forms or so—built it up over about five years. I don't know the exact number or line count but it was definitely in the 10's of 1000's of lines of code; really heavy forms. You know, it was a stock real-time trading application. And they wanted to really build on this app… but they weren't comfortable doing it in VB6, given the technology road map there, but they also knew it and we helped them out. We took a look [and asked], "What if we convert this thing to VB.NET?" We actually went through the exercises; we ran the project through the conversion tool. We had about four or five developers spend three weeks, just trying to get the VB.NET solution to compile—forget about run, we just want it to build. We got it to build and you'd bring up forms and there would be these goofy controls all over the place, nothing looked quite right. At that point we realized this isn't going to work. So, we [thought], "Okay, what if we just manually convert the code. We will just go to VB .NET, we will create new forms, and we will manually port that all over." And we came up with an estimate of about 18 calendar months for a team of about 10 people get this big application converted over.

Carl Franklin: I got to ask you, Jon, was this application the typical old school VB application where all the code was behind the buttons, or was it well separated? Jon Rauschenberger: I would call it a hybrid. I mean, there were non-visual business objects that encapsulated most or at least a decent percentage of the, you know, the business logic of placing an order or cancelling an order, that sort of thing. But there certainly was a lot of, what I think anybody would characterize as business rules and application logic embedded in those forms. Sometimes for good reasons, sometimes for bad reasons but it was probably pretty close to the typical, you know, VB6—a good but not perfect app that was built by some good solid VB6 [developers].

Carl Franklin: They gave it the old try but sometimes they didn't follow the rules. Jon Rauschenberger: Yeah.



Carl Franklin: With an app with that kind of legs, you bet, it went through a lot of different hands of varying skill and skills that evolved and rarely does the real code get cleaned up. Jon Rauschenberger: I was having some fun just reading through the code. I've been working with this client for a long time and it was kind of like a walk down memory lane of all the developers who we have worked with over the years. They'd all made their little contributions to the app and they are still in there.

Carl Franklin: So, you've obviously got a process now for dealing with this. I guess that's what we really want to hear. Jon Rauschenberger: Yeah. [So, the product] we helped Microsoft work on came out of this and essentially what we wanted to do. We [had] 150 forms [and] we wanted to pick 25 of them and convert those over to VB.NET and then release a new version of the application and then do another 25 and another 25. And the business was okay with 18 to 24 months of conversion process. They just weren't okay with getting nothing during that time [such as] no new releases in there. We came up with an architecture in .NET, VB.NET, [where] we could create forms, you know, [and] we would create business objects where we needed to. We actually ran the old VB6 business objects through the code conversion tool and they came through pretty clean and we compiled that into, you know, a managed DLL. We put a COM interface on top of [that DLL] and then we put a little bit of code in VB 6.0 saying when the user clicks on, lets just say the new order button, we made a message call on this COM DLL within the VB 6.0 world that's going to pop up a form which happens to be a VB.NET form. And now in the VB 6.0 process, we are hosting the .NET Framework in a common language runtime and we are side-by-side showing one form as the VB 6.0 form and one form as a VB.NET form. And what we are able to do, using that architecture, was take this application and over a span of about 6 releases, get the entire application ported over. Took us a little bit longer, so it took about 2 years instead of 18 months but we did 6 releases on that. And in the end, we kind of felt like, you know, "This feels like something that isn't probably unique to this customer."

So, we took it to the VB team and this is one of the things I love about the VB team. We said, "Hey! Look, this is what we did; we've got a good relationship with [this client]. Is this something you think [Microsoft] would be interested in making easier to do so that other people could take it and apply it [to] their needs?" Out of that came about a two and a half month project where we built a little tool kit—it's going to be available as a free download sometime this summer. I don't have an exact date yet but in the next six to eight weeks I would guess. [This toolkit] basically streamlines the process of creating a form in VB.NET—clicking a button, building your solution and now you have got a form that you can very easily pull into your VB 6.0 application just by adding a reference to a COM object and programming against what looks and feels like a VB 6.0 form but under the covers there is an Interop layer that's mapping those COM calls to the appropriate .NET objects; shelling the right forms. And [it] even allows you to do things like raise events, so when a user clicks on the button in your VB.NET form, you can raise the event back over to VB 6.0 and you can handle that event and it shows properties. We even went so far as to allow some concepts that don't apply to VB 6.0, like overloading constructors, to be offered in VB.NET and then through our mapping layer we turn that into initializers on the VB 6.0 side so you end up with an initialized method—which is kind of pretty common VB 6.0 if you want to initialize something. Carl Franklin: What I like about this is that it isn't like typical transitional kind of conversion wizards because the goal is not to have something that you are going to use forever. The goal is to have something that compiles, something that works, something that will get you to the next release when, maybe, the code will be replaced by 100% managed.

Jon Rauschenberger: Yeah, that actually was probably our number one design goal. The people writing code in VB.NET didn't know they were writing a form that was going to be hosted in VB 6.0. So we didn't want you to be constrained in terms of how you are going to design your form because this Interopping was going to happen. For that very reason when you are done with the Interop, if you ever do finish—say two years from now, you don't have the Interop anymore, we didn't want all this Interop goo, you know, sprinkled throughout your code that we talked about earlier—you'd never get cleaned up. Ten years from now, people would be looking at it and thinking, "What did we do that for?" So, we really try to keep a nice clean separation. You write that code, use a little toolkit we have—a Visual Studio add-in-that will generate the appropriate COM interface code for you—and you don't have to worry about any of that. Carl Franklin: That's great! Very very cool. So, you are looking at what—the end of the year before this comes out? Oh no, you said six to eight weeks.

Jon Rauschenberger: Yeah, it's going to be available as a free download from the MSDN site and the download includes the Visual Studio add-in. It includes a little helper class that we use for some of the Interop stuff. Two sample applications, the "Hello World"-style app and then a larger, sort of full-blown line of business application using Interop and then a bunch of documentation. And the other cool thing is that, at least as of right now, the plan is to release, if you need it, the source code for all this stuff. So, if you want to go in and tweak and change it around a little bit, that source code will be there. Our goal, though, is that no one needs to do that. Carl Franklin: Is there a project name, like a nickname for the project?

Jon Rauschenberger: Yeah, it's currently referred to as the "Interop Form Toolkit" and that is sort of a, working name. So, it may change but it will be something along those lines. And we do want to focus [on] solving one problem, which is, "How do I take a form written in VB.NET and host it in a VB 6.0 application as part of the migration path?" There is nothing in the toolkit that helps you convert your non-visual DLLs. There's nothing that helps you to direct at dataset problems. We wanted to focus on, "lets solve one problem and solve it well and let other people and other groups worry about providing some guidance around the other pieces." Carl Franklin: So, given that you have all this experience doing this conversion, let me ask you—what was, other than the Interop stuff—what was the most challenging thing that you had to come up against when you did this conversion?

Jon Rauschenberger: The data type problem was a bit constraining and that kind of carries forward into the toolkit. You need to be conscious of what data types you can marshal across the Interop boundaries and which ones you can't. And then the other piece—the two different forms engines. The VB 6.0 "Ruby" forms engines and the VB .NET WinForms engine, they do behave just a little bit differently. So, for example, in some instances where VB 6.0 fires a MouseDown event, VB .NET fires a button's Click event. And if you are a developer, just going back and forth, its kind of like jumping back and forth between C# and VB .NET, for example, that mental shift—you have to jump through when you go from one to the other. It's a bit of a challenge. Carl Franklin: What about the graphics stuff? I mean, I know there are some things that VB 6.0 applications relied heavily on the Windows API to do—things that VB couldn't do. I know that there are some things that you can do in the API that you can't do in .NET. I think, scrolling is one—like ScrollDC is one. If I can remember correctly, FindWindow, the FindWindow API—there is no equivalent in the .NET Framework for that.

Jon Rauschenberger: Right. Carl Franklin: So, did you ever come across those things too where you had to just, totally, throw a monkey wrench in the architecture and you had to redesign.

Jon Rauschenberger: You know, actually this was something I never thought I would do, but the FindWindow is a good example where we needed to do that; at least when our app was in hybrid mode. We need to find a Window and we didn't have great support and in VB 6.0, it was so easy. What we actually did was just create a VB 6.0 COM DLL, call the function, and then we'd call it in VB.NET actually. Carl Franklin: There you go.

Jon Rauschenberger: Most of the time our Interop was going the other way, where we wanted to do something that was easier in VB .NET and whether it was graphics or anything else—bonding threads or calling Web services and you know, that sort of thing. But that one instance, we did go back the other way. That's actually [where] I think Microsoft has changed their tone a little bit here. That's where I get excited about Interop. Its like, you pick the right tool for the job, build an application—you just don't care which language or technology you are using. And if we can smooth out some of these Interop road bumps, I think, it would become a much more thought-about architecture to say, "Let's create an app that's partially VB 6.0, partially VB.NET, partially C++ if we need to." The conversation continues online.



Comment and Contribute

 

 

 

 

 


(Maximum characters: 1200). You have 1200 characters left.

 

 

Sitemap