VB6 to .net

[N1GHTEYES]

The IT Gods here at work have decreed (without reference to the engineers - as usual) that, in the desktop upgrade we will be getting in about a year's time, VB6 will be scrapped and replaced by .net.

I've got huge piles of VB6 code (snippets, libs, apps - all sorts of stuff) totaling, oh, I don't know, several hundreds of thousands of lines of code. I have not used .net, but I have heard that unlike 4->5 and 5->6, I can't just run my VB6 code in .net and expect it to work.

So, firstly, can anybody confirm / deny this statement?
Secondly, can anyone suggest a ballpark figure for the effort required (say, per thousand lines of code) to convert from VB6 to .net?

Once we lowly engineers have been told something will happen, it is usually set in stone, so the chance of my persuading them not to do this is slim, but does anyone have any killer reasons NOT to convert? Is there, for example, anything that VB6 does which cannot be done in .net (or which is slower, or more difficult etc).

Does anyone want to champion .net and tell me why it IS a good idea to change?

Is coding in .net RADICALLY different? How much of a learning curve is there for a (moderately) competent VB6 programmer to learn to use .net?

Basically, any light you chaps (and chapesses) can throw on this, either to equip me to argue against it, or to prepare for it, would be appreciated.

Thanks in advance,

Tony

 

[N1GHTEYES]

Wow - the debate rages. I seem to have hit a nerve with this question. Opionion is clearly divided, but there seem to be a few common points of agreement. I'll try to tease them out and I feel sure someone will correct me if I've got it wrong.

1 Converting a VB6 app to .NET, for anything but trivially simple code, is very hard, and probably not worth it. I must retain VB6 capability to continue to maintain my old code unless it is worth a complete re-write.

2 .NET has the advantage of being thoroughly object-oriented, including proper inheritance. (does it support overloading?)

3 The database aspects are worse because you are compelled to use bound data.

4 The database aspects are better because you are compelled to use bound data.

(OK, that's not exactly what you might call full agreement. The DB aspects of this debate create small whooshing sounds as they go skipping over my head. I don't do DB apps, I never have, and, until I come across a case where a project needs it to the point where it is prepared to pay for me to learn it, I probably never will)

5 VB.NET is better because it is more compatible with other members of the .NET family.

6 There is a considerable difference between coding in VB6 and VB.NET, requiring substantial learning.

7 Speed - the only comment I can find so far indicates that, for real-time instrument sampling at least, VB.NET is considerably slower.

That seems to sum things up so far. I've a feeling there may be more to be said however.

For example, I've yet to hear anyone comment on whether VB6 or .NET runs faster for a given task, in "normal" operation.

How about compatibility w/ VBA? I frequently explore a problem using Excel to knife and fork an approach, while working up VBA code to tackle parts of the required analysis. If the problem ultimately requires a faster solution, or must be repeated across lots of data sets, I then convert the analysis solution to a VB app. Going from VBA to VB6 is fairly straightforward. Can the same be said of VB.NET?

Tony

 

[TipGiver]

Let's go.

1. Right. A big vb6 project should be kept and upgrated in vb6. If for some reason you need to go to .NET, then write it from scratch. It will be much easier.

2. OOP is great. After using OO for some time you will see that it is better than non OO programming. Yes, it supports overloading.

3 and 4. You can use early and late (!) binding.

5. .NET is a new programming platform.

6. Ofcource, since .NET is OO programming 'package' (VB, C#, J#, VC++).

7. Yes and no. You can do some code improvements/optimizations... Theoritically I could write many pages on performance. You should post something real in the VB.NET forum to get an answer for a specific problem.

VBA. Vba is like vb6. You will keep on writting vba code in the excel code editor. Things are a little different, but this should not scare you. The intellisense with the tooltips are very helpful.

 

[HarleyQuinn]

Got to say, you're not forced to use bound controls for the database aspects of .NET at all. Using datatables and datareaders filled with data retrieved from the oracle and sqlserver clients (this is only one way but one which I've found to be very useful) are very similar to using recordsets...

HarleyQuinn
---------------------------------
Get the most out of Tek-Tips, read FAQ222-2244 before posting.

 

[N1GHTEYES]

Ok lets try a concrete example. Lets say I have some image data, say 1000 frames where each frame is 640*480 integers. A typical, simple task would be to find the max, min, mean and sigma of each frame, then find the max, min, mean and sigma of each frame's max, min, mean and sigma values. As far as I'm concerned, this is bread & butter coding.

Assuming I was working on the same machine, would VB6 or VB.NET do this kind of number crunching faster?

 

[JoeAtWork]

>> you are compelled to use bound data

That is not correct. People who say this are probably the same ones who think that the only way to get data from a database in VB6 is with a data control.

Having said that, the binding in .NET is much more flexible and practical then what was available in VB6.

 

[avanderlaan]

Nighteyes,

There is definitely no requirement to use bound data. I found ADO.NET to be a better implementation than ADO. That said, the database update rate seems to be a bit slower than ADO/VB6 when executing the same stored procedures on SQL2000 in a repeated loop performance test. ADO.NET performed better than ADO/VB6 in the same test when run against SQL2005.

 

[TipGiver]

" Ok lets try a concrete example ... "

You can use arrays. [see Array.methods]

Why do you ask such things? With .NET you can do whatever you did with vb6, plus a billion others. Also some things much easier, plus the fact that the .NET controls are much much improoved.

 

[BobRodes]

N1ghteyes,

IMO, an absolute MUST READ for someone in your position is Dan Appleman's "Moving to VB.Net: Strategies, Concepts, and Code." An outstanding book, with a lot of relevant information in an amusing and readable style.

HTH

Bob

 

[N1GHTEYES]

Bob:
Thanks for the recommendation. I'll see about getting it added to our dept's library.

TipGiver:
I never doubted that you could do that kind of thing in .NET. All I was asking was how the execution speed of code doing that kind of task would be likely to be faster, slower, or much the same in VB.NET than in VB6. The reason I suggested that kind of task is that it typical of the kind of analysis I spend my time doing.

Tony

 

[TipGiver]

NIGHTEYES,

It depends on the quality of your code. Anyway, there are some other tools, e.g. the NUnit test that help improve your code (analysis test etc.)
One other, is e.g. to create a console app that will get the arrays and return the data you want (min, max , etc). That way you will gain some speed, as you won't have any GUI for that.
Hope you get what i mean.

 

[N1GHTEYES]

TipGiver:

I get what you mean - I'm sure there are loads of ways to write more efficient code - but that was not what I was asking. What I really wanted to know was whether VB.NET gives any inherent efficiency / speed improvements over VB6?

I realise there may not be just one answer - it may be faster at some things and slower at others. That is why I gave a simple example of the kind of thing I was interested in.

The question of speed has been raised several times now in this thread, and so far, nobody has indicated any way in which VB.NET has a speed advantage over VB6.

- Tony

 

[BobRodes]

<Assuming I was working on the same machine, would VB6 or VB.NET do this kind of number crunching faster?

I suspect that very few people have an informed opinion on this. (Dan Appleman is one of them, no doubt, and I also would think that Francesco Balena--the author of a couple of my other favorite books--is.) I also suspect that the results of such a test, should you choose to conduct it, would be most interesting. Furthermore, if you should devise a test, you'll probably get a lot of input as to how to tweak the code to squeeze the most out of it.

Suppose, for example, you find a way to do this in VB, and go out looking for improvements in .Net. You write something, and it runs a lot slower. Some people will tell you, let's say, that it's because you have to do a JIT compile of the .Net code before you can use it. Sounds horrible, not quite true, and your real problem is that you didn't understand boxing so one of your stack-based variables got boxed in the middle of a loop. VB is definitely faster here.

Suppose you find a very fast way to do this in VB, let's say using some of the API wrapped in a COM object. You could still use the COM object in .Net, and probably not find much difference in code execution.

Let's also say that you find that the best way to do your calculations is to create some sort of multiple thread algorithm, rather than using the limited multithreading capabilities that VB affords. Since .Net supports full multithreading, and you have unlimited time on your hands to implement a robust multithreading model, .Net is definitely the hands down winner here.

So, inherent efficiency/speed improvements? Yes and no. It depends. One could argue both sides. And on and on we go...meanwhile, that's a great book, and will probably give you a sense of what you're looking for. For what it's worth, I personally doubt that VB is faster in this sort of situation, assuming optimal .Net code, but again, I would be fairly quick to bow to others' expertise in this.

Bob

 

[JoeAtWork]

I don't think anybody switches to .NET with the expectation of a speed increase. I wouldn't be surprised at all if code in VB6 is somewhat faster than equivalent code in VB.NET. That wouldn't make me not choose .NET, because I think that code maintainability generally trumps slightly more efficient code.

Quite frankly, if you are looking for super-optimized code, then neither VB6 or .NET are the best options. You would probably be looking at C or assembly language.

 

[TipGiver]

Yes, VB.NET is a little slower than vb6.
But the pros of using the .NET platform are many.

 

[BobRodes]

<I wouldn't be surprised at all if code in VB6 is somewhat faster than equivalent code in VB.NET.

I would.

 

[kss444]

For what you are doing N1ghteyes I don't think that neither vb6 or .net is faster than the other. I think for now you should keep your existing vb6 apps as they are, and for any new development use .net (preferably 2.0 with VS2005) and if time allows look into rewriting the vb6 apps.

Also if you have any vb com dll's that you use you can easily convert them using .net Interop. This lets you use your existing vb6 com dll's in .net for any new .net development, until you have time to convert the com objects.

 

[N1GHTEYES]

This subject certainly seems to arouse some interest - 36 replies so far, more than any thread since early June by my reckoning.

Thanks to all who have replied.

Lots more of the later comments have been positive (in favour of .NET), but I'm still not sure I'm convinced it is worth the effort involved.

1 I can't convert my old apps - I have to re-write them, or persuade the powers-that-be to let me keep VB6 as well (which will probably be impossible).

2 It will probably take several months to get fully up to speed on .NET because it is so different.

3 .NET is probably not intrinsically faster. Certainly, speed is not a major argument in favour of it.

4 It may or may not be better for database type stuff (there is undeniably some debate on this) - but I don't care anyway coz I don't do DB stuff.

5 It is much more OO, which means (nominally) that code is easier to maintain. Personally, I'm yet to be convinced that OOP is an improvement. I think it is a cute idea, and programmers are the kind of people who like cute ideas, so they have latched onto it, and enjoy exploring the concept. However, even if it IS an improvement, I'm not convinced it is enough of an improvement to justify the effort involved.

Tony

 

[strongm]

>I'm yet to be convinced that OOP

There are quite a lot of people who have begun to suggest that OOP has failed to deliver on all its promises

 

[Davidprince]

Nighteyes
I read through the plethora of comments with amusement because none of them answered your real question which was the second part of your query: "can anyone suggest a ballpark figure for the effort required (say, per thousand lines of code) to convert from VB6 to .net". As many said in the 37 replies it's a case by case situation.
I think that I would suggest to your IT gods that you do things in reverse, that is to say start the learning curve on VB.net but retain and maintain your current suite of VB6 programs. Once you and your staff are up to speed on .Net start the conversion process. However, as a reminder to those gods send them emails on the cost of conversion.
Timetable: 3 - 6 months to become proficient at .Net
9 - 12 months to convert programs

Have you got data on the time that was taken to write the VB6 programs? If so, that will be ballpark to convert to .Net.
Lastly, as was suggested in one of the replies don't attempt to modify a VB6 program to .Net but rather start from scratch.
By the way by the time all this happens everyone will have switched to Linux!
Regards
David

 

[N1GHTEYES]

Strongm:

I felt slightly mischievous when I wrote the comments about OOP. I know it is supposed to be the best thing since Babbage, so I was expecting cries of "Heretic!" and, possibly, "Burn the Witch!". As one of the most prolific and respected members of the forum, your response has thrown me slightly.

David:

Thank you for your comment. Yes, it seems to be a common feature of many threads that every question is answered except the one which was asked. Though it has to be said that, in this case, many of the responses were relevent and did address the issue, if not that specific point.

Everybody pretty much seems to agree with you that doing the transition gradually is a good idea. The issue is whether I'll be able to get the plans changed to accomodate it.

There are loads of tools I've made with VB, but the main one has about 80,000 lines of code, and has grown steadily over the past 10 years, with a major re-vamp about 5 years ago. That's the one I REALLY don't want to have to re-write.

by the time all this happens everyone will have switched to Linux!

Heretic! Burn the witch!

Tony