Fog Creek Software
Discussion Board

Welcome! and rules

Joel on Software

Migrate Vb6 app to .net

Hi everybody,
we have a vb6 app that we plan to migrate to .net
This migration cannot be done instantly (discard the old vb6 app) so we have figured that the best way is to do it step by step.
As a result we will be writing code to call the .net objects via com interop.
However it would be good if we could display the .net form as mdi children of the vb mdi parent form

Migrate to .net
Monday, February 14, 2005

(continued - press the button by mistake)
Do you any way to do it?
Do you have some good links to tutorials usefull info etc.

Thank you very much in advance

Migrate to .net
Monday, February 14, 2005

Might be easier to work the other way around. Create the .net app and call the old VB code via interop.

As to your original question? I don't know if this is possible or not.

Monday, February 14, 2005

We have already thought of that but the vb6 code is very unstructured.

Migrate to .net
Tuesday, February 15, 2005

Then perhaps structuring the old code should be the first step.

Tuesday, February 15, 2005

I'm someone who's still in the long process of converting a 15KLOC VB6 app into a .NET implementation. This source evolved over 2 1/2 years while the conversion process is taking around 6 months with probably a month or two to go on completing it.

The big issue I've faced is that translating VB6 code to VB.NET requires an inherent change in design. I went with the "big-bang" approach to conversion, and while the code itself compiled within 3 weeks of mass conversion, code correctness still has a LOT to be desired.

If I did this again, I would probably take a much more step-by-step aproach to conversion, starting with the interface and working my way backwards. Interop with VB components, while patchy does work in practice and it also means that as you re-implement sections of the program in .NET you can also incrementally improve upon the design of the program.  The disadvantage of this approach is that any interop 'bugs' (1-bound arrays anyone?) will cripple the whole program.

I'm finding the need to change whole cross-sections of my program because of differences in the way enumerations and arrays are handled for example. Having a dormant but sound re-implemention of the underlying design could speed things along without introducing annoying conversion bugs. And there are plenty of those...

Wishing Visual Fred was backwards compatible
Tuesday, February 15, 2005

A couple of short tips

The best path to conversion is to refactor your VB6 app to a design that work both in VB6 and VB.NET. Refactor a copy of VB6 app, test the hell out of it. And when it 100% do the conversion.

1) If you use global multiuse classes in a supporting activeX DLL; make a copy of your application and refactor it so it make the call on a object variable. I.e. if you have a sub foo in a global multiuse class called myfoos.

The easiest way I found to this is make a module called HelperMod in each project that references MyFoos. Make a variable called gMyFoos as MyFoos. Make a sub in the module
called Foo with the same parameters and then make the call on gMyFoos.Foo. Then use this module in each project that uses MyFoos

2) Make sure that parameters to properties on classes you use as interfaces are ByVal. VB.NET will choke on trying to implementing a read/write property with Byref  parameters.

I.e. Property Let MyProp(RHS as Integer) needs to change to Property Let MyProp(ByVal RHS as Integer)

3) non-Modal forms will cause an error in a .NET exe if displayed from a ActiveX form.

The message is "Non-modal forms cannot be displayed in this host application from an ActiveX DLL, ActiveX Control, or Property Page".

4) A background of transparent on a panel or control only pertains to the forms background not any control beneath it in the zOrder.  We used overlapping controls in some forms to have a revealing effect with some text on top.

5) If you use control arrays in forms be prepared for some MAJOR refactoring.  The easiest conversion I found is to inherits a class from the desired control. Add a Index field and add them to the form the .NET way naming txtFoo1, txtFoo2, etc.

Then define a array the same name as your old control array. setting element 0 to txt Foo1, 1 to txtFoo2, etc.

Use AddHandler to set all the added controls to the same event handler

AddHander txtFoo1.Change Address of txtFooClick
AddHander txtFoo2.Change Address of txtFooClick

In the handler cast sender to devired class and call the index and the rest should work the same as the old version

    Dim aTextFoo as TextFoo
    aTextFoo = sender
    Select Case aTextFoo.Index
' Old VB6 code should work as before

6) If you do extensive drawing on a printer or screen. Write a adapter class for the VB6 app with a interface that will work with VB.NET. Change all your code to send the drawing through the adapter.  Test the VB6 app and make sure it work like it did before.

Then when you convert to .NET, You just have to implement the interface passing calles to the Graphics class instead of the VB6 form, picture setup.

I hope this helps
Rob Conley

P.S.  In my opinion whoever is responsible for VB.NET had NO respect for prior version of Visual Basic. In opinion the team designed a outstanding new car and then promptly choose to drive over a cliff with it.

For example the changes to long and integer. No reason for this especially when .NET was designed to support multiple languague. In C# int and VB integer emit the same thing. Was really such a mental chore to have Integer emit the IL for a .NET int16 instead of a int32.

Dimensioned arrays, I can accept that by design .NET only supports zero based arrays. But the best conversion would have to been to continue to allow the declaration of arrays that go from any range to any range and during the compiliation to IL fix up the array addresses.

We have over a dozen projects where somebody is making a language that emits .NET IL. There is no reason why Microsoft couldn't have made a VB6.NET where you could copy and paste code from a VB6 application.

There still would have been behavior changes and some feature loss. But it wouldn't be the abomination we have now.

VB.NET is a kick butt langauge but the loss of a good conversion route from VB6 showed a serious lack of respect from Microsoft.

Rob Conley

Rob Conley
Wednesday, February 16, 2005

One word:


(or was that two?)

Warren Porter
Wednesday, March 9, 2005

*  Recent Topics

*  Fog Creek Home