Migration from VB6 to VB.Net problems

M

mjohnson3091

Freshman
Joined
Aug 10, 2004
Messages
31
Location
Lancashire, UK
As this is my first post I'd like to say Hi to everyone first.

I have been playing at migrating or current multi-tier VB6 program to VB.Net. I used the migration wizard, which did a reasonable job, but also left me with some problems. Our VB6 application top level would spawn off clients which were ActiveX exe's. Upon migration the wizard suggested that the program should be converted to a DLL. I managed to get the program working with a single client, but the problem is, that when the object is created, it doesn't appear with it's own process ID and therefore it is handled differently. When I try to set the object to Nothing this works fine, but trying to instantiate it again gives me "Error 387 - Set not permitted". Is this something to do with it being a DLL and not an Active EXE?

I'm using the following code - this is cut down, but should give the idea

Code: 
Private WithEvents objSession1 As BECSessionManager.RFSession

'...Within the code (tcpserver Accept)
objSession1 = Nothing
objSession1 = New BECSessionManager.RFSession

' ...within the code (tcpserver Disconnect)
objsession1=Nothing

Any suggestions would be really appreciated.

Thanks in advance

Mark J.
 
I don't think I can help you on your specific problem, but I can echo what the Powers That Be around here would say.

Ditch the migration tool. It often produces faulty code. I believe it gets exponentially worse. It's alright for a straight forward app, but the more complex it gets, the more chances of code messing up.

my advice is to run the wizard. You can now see what it's doing and what the wizard has translated your code to.

Keep that open.

Now I'd open up VB6 and .Net and translate the app over procedure by procedure, class by class. Refer to the other code as needed, but also refer to the MSDN and these forums.

At best you're going to get some crappy code from that wizard. At worst you're going to get some code you think is good and doesn't work properly down the line. The wizard uses many legacy VB compatibility functions, especially for file access which are 1-5 times slower than the .net functions.

Just my opinion, worth the paper it's printed on :)
 
The wizard is useless at best and a downright menace at worst - when it works it doesn't take advantage of the .Net framework and merely ports the VB6 code (hacks, API calls etc) as is. Often it wraps simple .Net functionality with an extra layer (Microsoft.VisualBasic.Compatibility.dll). It doesn't even manage to port the common dialog / common control functionality despite the fact there are .Net equivalents - it still wraps the ActiveX components.
In nearly all cases if your app is simple enough for the wizard to migrate without errors then you could have probably easily re-written it - anything more complicated and it will fail in many interesting, but not recoverable, ways.

To really take benefit of the move it's often worth considering a redesign of your app to take advantage of the newer features (better interface support, inheritance, delegates, newer controls, the class library, exception handling etc....)
 
Thanks for the feedback guys (Nice to hear from someone down the road PlausiblyDamp).

The intention was to convert the program to .NET using the migration tool as a rough and ready way in to .NET and to get a little more used to the environment, the idea was then to twist the MD's arm and get us some training about the framework and the ins and outs of .NET.

Phase 2 of the project was to rewrite a lot of the code based upon our knowledge gained through the training to make better use of the framework and move away from the legacy VB code in the project to a "pure" .NET based solution.

Granted this isn't the best way to approach it, but if I don't show any initiative in wanting to go forward, there is no way he is going to look at moving to .NET.

So I suppose I must ask the question again in regards to the ActiveX Exe - any suggestions???
 
Active EXEs don't have any direct .Net equivalent, probably the best thing to do is move the reusable code into a classlibrary and have the .EXE application call into this classlibrary. If you require multiple simultaneous calls to this classlibrary then you may want to investigate threading rather than spawning multiple processes.
 
PlausiblyDamp said:
The wizard is useless at best and a downright menace at worst - when it works it doesn't take advantage of the .Net framework and merely ports the VB6 code (hacks, API calls etc) as is. Often it wraps simple .Net functionality with an extra layer (Microsoft.VisualBasic.Compatibility.dll). It doesn't even manage to port the common dialog / common control functionality despite the fact there are .Net equivalents - it still wraps the ActiveX components.
In nearly all cases if your app is simple enough for the wizard to migrate without errors then you could have probably easily re-written it - anything more complicated and it will fail in many interesting, but not recoverable, ways.

To really take benefit of the move it's often worth considering a redesign of your app to take advantage of the newer features (better interface support, inheritance, delegates, newer controls, the class library, exception handling etc....)
Click to expand...


I couldnt agree more, when i tried migrating a program to vb.net from 6.0 that took out .wav's from a res file and played them in the windowsmediaplayer control... all it did was like add tags to all my code saying it was vb 6.0 code @_@ which of course the program did run fine, but with the same exact code.
 
Back
Top