Printable View
I have a program I made in VB 6 which has probably hundreds of thousands of lines of code.
Is it complicated to convert it to VB.Net or is it not worth it?
My main problem is that VB 6 doesn't work in Win 7 so I need to use the XP emulator each time I make an update.
Thanks
Whether it is worth it or not is up to you.
I'm going to give you the same advice I've been giving people for the last 7 years regarding this: Visual Studio does come with an "upgrade wizard" (VS2010 is the first on that doesn't) ... but using that will cause more problems than it's worth for anything more complicated than "Hello World" ... You're best bet it to scrap the existing app, treat it as if you are building it for the first time... do it over from scratch - get requirements, do a design, development, testing, etc. Now, that's not to say you can't or shouldn't recycle part of th code from the original app... but that should only be done in small, select cases.
-tg
Thanks, that answers my question, it's not worth it. There are years of work in this program and it's just not worth redoing it from scratch when the only benefit I see would be not having to use the XP emulator to make updates (of course I have no idea what the new features/functions of .net are as I've never seen it).
If ever I wanted to make a new program, what does vb.net have over vb 6 in terms of features and functions? Is the code still the same, mostly the same, or completely different?
Thanks
A bit of further advice. I fully agree with techgnome about re-building your application from scratch but if you start doing this (as I've seen many VB6 programmers do) try to avoid VB6 approach to programming. You can probably mimique the behaviour of your application re-written in vb.net but you won't take advantage of the .Net Framework. The point is that many things we did in VB6 one way should (and probably must) be done differently in vb.net. .Net framework offers a great deal of power to a programmer but it would be useless if the programmer doesn't use it. Study .Net framework first, especially in what ways it is different from VB6. This will make things a lot easier for you later.
Exiting and future operating systems will support .NET code. The same can not be said for VB6.Quote:
Originally Posted by aab1
C. Completely differentQuote:
Originally Posted by aab1
I tried this also with a major project. Believe me, you get a pile of sh$t instead a working application.
I've rewrote the whole application from scratch en must say, it's neater, cleaner, faster and above all i learned vb.net much quicker. :)
I would concur with what has been said.
However, do you need to upgrade it? I understand that the next MS OS will not support VB6 (that may change), so is a compelling reason to update the application. Aside from this, if it works, there may not be an urgency to do so.
Of course, if the program needs constant maintenance, then that may be a different story. Even so, rather than a clean sweep upgrade, you can use .NET components in a VB6 application. Rather than a wholesale 'start from scratch', simply remove the troublesome components and rewrite them in .NET. This gives you an opportunity to gradually migrate the app without looking functionality, and learn some of the ins and outs of a new IDE and new language.
a wholesale rewrite can be a time consuming (costly) approach to garner the very same results you already have, with the potential for not even making that. That is, it is a big risk.
As an aside, VB6 applications work in Windows 7, the development environment doesn't.
I agree with everthing said so far.
I am sure many of us face the same dilemma on a daily basis; carry on mantaining legacy VB6 apps or consider the leap to .NET.
If, as myself, you find that migrating in not a realistic option at this moment in time I have some good news: Both the VB6 runtime and IDE do work in Windows 7.
I've never got the VB6 dev program to run win Win7, I have to keep running it in the Windows XP emulator, are you saying there is a way to do it without the emulator?
Also, why wouldn't vb6 apps work in future windows versions? Wouldn't it be just a matter of including the proper dll/ocx files with the installer?
If you meet these criteria, you might be able to convert it in less than a year with a team of people at your command:
- You have written 2 or 3 large applications in VB .NET and know it very well.
- The VB6 application uses no third-party or custom controls.
- The VB6 application is impeccably documented and has a full suite of automated tests that guarantee it meets the documentation contracts.
- The VB6 application is perfectly tiered so that you could replace Access (or whatever DB it uses) with text files in 40 man-hours with no bugs (it doesn't have to perform well in this state.)
- Every developer who originally worked on the application is present, experienced in .NET, and on the project.
- The VB6 application uses no API calls, COM servers, or any other mechanisms for interoperability with external code.
If you meet all of those, I'd say it's possible to do a pretty straight port. The tiering, documentation, and tests mean you won't have to make many design changes to the business logic; your biggest task will be WinForms conversion and the data access layer. With the right documentation that's just a bunch of tedium; nothing difficult.
The more of those criteria you don't meet, the more difficult a successful port will become. Without the documentation, tests, and original developers I'd argue even a from-scratch rewrite is destined to fail since no one person can tell you if the new application behaves like it should.
Now's the part where I try to sell you on a port.
If you don't meet the criteria above (and I'd argue it's as rare as a unicorn to find a large-scale project that does) then I promise there are little pieces of horror scattered throughout the code. If someone reports a bug, how often can you fix it in less than 10 minutes? When's the last time a new person was added to the project and how long did it take for them to make meaningful changes? Odds are the answers to those questions don't paint a nice picture of your VB6 application. (I'm not picking on your application; as I said I haven't touched a decade-old piece of code that didn't have these problems.)
So you have to look at the big picture. You've already spent X on the project. Right now, every new feature costs Y once you factor in labor and risk. We'll call P the probability that some new bug or requirement will make the program unusable until it's fixed. X and Y are measured in both time and money; for example you might have spent 2 years and $1.5m on X and the last bug (Y) might be 2 man-weeks at $1k.
The traditional reason to avoid the total rewrite is because that cost X of the original effort is scary and more than the short-term cost Y of fixing an individual bug.
Here's where the hook comes. How much do you spend in a year on the product? Add up all of the Y costs. Now annualize them. Now consider how much has been spent on maintenance since the initial release of the product. It's a well-accepted fact that most software spends the bulk of its lifetime post-release.
If you're missing any factors that make maintenance easier (original developers, documentation, automated tests that take less than an hour, etc.) then odds are Y is fairly expensive. A rewrite is your chance to take the steps that make maintenance of the new product (Y') less expensive. You'll have to pay for the up-front development (X'), but if Y' is significantly less than Y you end up in a "pays for itself" scenario.
There's another problem waiting in the wings. Remember P, the probability that some showstopper bug or requirement change would appear? Rewriting the software and including factors that decrease maintenance time won't necessarily reduce P (for a rewrite they might increase it!) but since Y' uses less time and money than Y you might come out ahead. The fun way to say this is a lower Y' means you'll be less likely to spend a weekend or overnight visit in your office.
Finally, there's Z, the ugliest cost of all because it's a complete unknown. You're having VB6 compatibility issues; these aren't going to go away. Microsoft has committed to supporting VB6 in Vista and Win7 for a few more years, but there are no promises beyond that. XP mode itself doesn't seem to have a lifetime guarantee; if MS doesn't feel it makes business sense they might drop it. What's your company's plan for if MS drops VB6 support *and* XP mode? In that case you won't be able to use the application at all until it's rewritten. Odds are MS won't do that without warning, but how long is soon enough? 6 months? 8 months?
There's other factors associated with Z. Since VB6's continued support is dubious, less people are starting new projects in VB6. The majority of positions for VB6 development are maintenance of older, mission-critical applications such as yours. Less graduates are gaining experience with VB6. These two facts combine to form one thing: as time goes on there will be fewer VB6 developers to choose from. Sure, graduates can learn VB6, but do you think they'd rather accept a position with a company building social networks poised to be the next big thing or maintaining internal purchasing systems that no one outside of some company will ever see? On top of that, would you trust your decades-old, mission-critical system to some newbie that hasn't ever worked on a project that took more than 24 hours to complete? Consider the experienced VB6 developer. What would make him want to jump from his decade-old project with which he has 8 years of experience onto your decade old project of which he knows nothing? All of this combines to make one thing true: as time goes by the demand will focus on experienced, eager VB6 developers but the supply is dwindling fast. Experienced, eager VB6 developers are already hired and it will take large salaries to tempt them away.
In short, Z is a term that increases over the duration of the project until it is rewritten. There are some events (loss of XP mode, loss of VB6 support) that will cause Z to be of infinite cost. The risk of this event increases as time marches on.
For an analogy, Bob Powell makes a good point. Right now it's painful to run your application becasue there's some VB6 compatibility issues; it's like an ache in your foot. So long as you hop on one foot (use an emulator), the pain goes away. But every day you have to climb a set of stairs and that jerk in the other company nearly knocks you over as he goes up (if your competitors have already rewritten, they are more agile than you.) You're afraid to go to the doctor because he might say you need surgery (you don't really want to hear someone tell you it's worth rewriting the project, so as soon as someone makes it sound hard you happily accept the workarounds.) Unfortunately, the risk of infection, falling down the stairs, or having that jerk knock you over means you're going to have to do something (you should really hire an independent architect to examine your source code and give you advice; otherwise your company might lose even more money than a rewrite would cost if you hit a maintenance hurdle that can't be overcome.)
It's very easy to ignore the long-term costs of keeping your software as-is because the short-term costs look so small. A rewrite can be a hard sell in the short-term but the long-term costs might justify the action. I've seen too many companies fail because they only focused on the short-term and made moves that were damaging in the long-term. I think you should get some external consultants to give you advice.
Start over from scratch.
When i finally realized the only way to do this was to start over i had a very hard time with some concepts of the way things are done in .net.
Once i got my head around the .net way i realized that you can do much more with far less code.
Thanks for the detailed reply.
Let me give you more details about my program:
This is a program I designed myself about 5 years ago, at first it was pretty basic and took maybe 2 weeks to get something that did the job and could be sold. I've continuously updated it with customer suggestions and it is now a fairly complex program with about 7000 copies sold.
I have absolutely zero experience with vb.net, I have no idea what it is, never seen it and know nothing more about it than that it is called "vb.net" (if I'm even right about that).
I would like to have a look at it to see if a complete rewrite would be worth it, there are a few limitations in my software that a near complete rewrite is likely the best solution for anyway (even if I were to keep it in VB6).
What is the best way to learn the changes between VB 6 and VB.net?
Thanks
The VB6 IDE still works in Windows 7 as I am currently using it in that set-up.Quote:
Originally Posted by SJWhiteley
Can someone tell me how to make VB 6 IDE run in Windows 7? All I get is a boatload of errors, I need to run it in the XP emulator.
It is my opinion the best way to learn the changes is to throw away your VB6 books and learn VB .NET. This isn't the only VB .NET forum I frequent and in my experience 25-30% of posts are made by VB6 programmers finally making the change that start writing code as if they were still writing VB6. This can get you pretty far, but eventually they hit some barrier and turn to forums for help. The problem with this approach is by the time they get here they've spent so much effort on the rest of the application they don't want to hear, "This architecture won't work, .NET doesn't work best that way."Quote:
Originally Posted by aab1
Pick up a VB .NET book (I recommend anything from Wrox Press) and read it as if you didn't know VB6. You might occasionally find stuff that seems familiar; it's appropriate to note "this feature is like a feature VB6 had". You want to avoid thoughts like "This looks like VB6, I don't need to look over it." If you get stuck, ask for help immediately. If you only know how to express what you want in VB6 code, that's fine. Code can sometimes provide better explanations than words. Again, the dangerous thing is to tell yourself this is VB6. It's not.
Another suggestion if you want to take things further: invest some time in learning language-agnostic application development practices. Read books about Design Patterns, particularly Presentation Model patterns like Model View Controller, Model View ViewModel, Passive View, etc. These tools help you write good applications in *every* object-oriented language, not just VB .NET. Learning these skills makes it easier to learn new languages. I strongly recommend becoming at least familiar with C#; almost all of the good language-agnostic books use C-like languages. Learning this stuff helps you use OOP the way it was intended. If I had to recommend a good start I'd say Head-First Design Patterns is a great starting place; it taught me more about OOP than 4 years of experience did.
The friendlier suggestion is to look at the MS documentation for this.. Note it's for VS 2008 and there's no help available for VS 2010. This help is likely to disappear in a year or two so use it while you've got it. I have no idea how accurate it is because I've never actually used VB6, just used my familiarity with syntax to diagnose problems from time to time. I still feel like the best way to approach it is "I am a new VB developer", but it may be because I dabble in so many different languages I'm accustomed to that style.
I've never tried it personally, but everyone I've ever talked to about it had no troubles. You might have to fiddle with the compatibility settings to make sure Win7 doesn't try to apply Aero and visual styles to everything.Quote:
Originally Posted by aab1
I have vb6 running fine in windows7 32bit don't know about 64bit
I'm running VB6 on Windows 7 64-bit. Run it in admin mode. Seems to be the only way I was able to get it to run.