VB6 vs. VB.NET - Comparison
This is sort of a philosophical question : is VB6 "going away" due to lack of MSFT support and their vision for ".NET" ? I've heard that migrating to VB.NET from a learning perspective is pretty tough, but I'd also like to know about features and performance.
1) Is app. development in VB6 a "dead-end" ?
2) Can VB.NET create native DLL's and ActiveX DLL's like VB6 ?
3) Does the code run as fast with VB.NET as VB6 compiled code ?
4) Is it worth the effort to learn VB.NET or should one just start from scratch and learn C# ?
5) What about all of this .NET "interopt" crap I keep hearing about and the "managed" DLL environment ? Is this a pain or performance burden ?
TIA !
Re: VB6 vs. VB.NET - Comparison
It's not a philosphical question at all.... it's rooted in cold, hard facts.
0a) Yes, VB6 is going away..... eventually. MS's support for it ended a while back, and full on support for those that can afford it, ends next year if I remember right.
0b) It's not really all that tough. An IF statement is still an IF statement. It's mostly a matter of being able to understand OOP concepts and being able to do a paradigm shift.
1) "dead-end" - Only if you let it be. Some people don't want to change. They'd just assume stick in VB6 for the next 20 years. In 15 years, we'll be making fun of old curmudgeon vb6'ers the way we make fun of old curmudgeon COBALers from years past. Personally, I'm embracing the future w/o forsaking my past. I'm slavitating over things I can do in .NET that I can't do in VB6 (true inheritance! Overloading! Generics! oh-my!)
2) No. It creates .NET ones. They get compiled into a semi-intermediate state of MSIL. Final compilation is provided by the JIT at run-time.
3) Yes.... and no.... It's hard to compare. Generaly speaking, at least the first rin of a .NET app will be slower because it has to go through the JIT first. Subsequent runs should be comparable.
4) That's something only you can answer. WE can't help you there.... you know your skills. If you've been heavy into VB6 and earlier, VB.NET isn't a bad way to go.... otherwise many say C# is the place to be.
5) In .NET, there's two types of code bases: Managed and Unmanaged. Managed is .NET, the framework, your code, etc. Unmanaged is everything else: C++ code, external DLLS, everything that isn't .NET. Interop is a wrapper around a COM (or any unmanaged code base) that allows .NET to use & consume an Unmanaged library. INTEROPerability. It is neither a pain nor a performance burden if properly done. There is a small performance hit when going through an interop layer, but that's because it's got to go through it to get where it's going.
-tg
Re: VB6 vs. VB.NET - Comparison
Welcome to the Forums.
We have many threads on vb 6 vs .net. A search of the forums will turn up many good long threads on it.
If you learn vb.net then you are learning the framework too which is common among the .net languages. This makes it easier to switch and learn a different .net language when its only basic syntax you will need to learn.
Re: VB6 vs. VB.NET - Comparison
I would just like to note that there is problems when dealing with arrays in Vb.Net and if you were to learn a language i would suggest moving straight into C++ not Vb.Net.
Re: VB6 vs. VB.NET - Comparison
Every language has its pros and cons. C++ has issues because you have to manage memory yourself or your app will suck up resources.
Re: VB6 vs. VB.NET - Comparison
Just to answer everyone:
1) I DID perform a search using "VB6 vs. VB.NET" and got nothing back.
The search engine on this site is "challenged".
2) C++ ? You meant C#, right ? Why on earth would ANYONE desiring a rapid application development language move to C++ ?
3) Cobol reference: interestingly, I see the same problem with VB.NET as I saw with Cobol: TOO VERBOSE. Without Visual Studio, programming VB.NET would be a huge hassle and very unproductive. A similar example exists today with INI files vs. XML files. My gosh, XML sucks when storing a handful of important system parameters/values. With an INI file, you can instruct a user (in an emergency) to quickly edit the INI file and restart the app.
4) OO vs. Procedural : certainly for some large projects, OO is the way to go....but what about speed of dev ? OO requires huge, up-front planning and design. And, OO is very design sensitive. If done wrong, you must throw it away and start over.....risky business indeed. Naturally, for large projects, a good OO system is much easier to maintain.
5) .NET "interopt" - IMHO this stinks because the O/S is STILL DLL-based. If Win/XP ran in the CLR, it would be a different story. If anyone is building reatime applications, using .NET appears to be a foolish choice. For RAD and app prototyping, I think VB6 is going to last quite a while longer.
Re: VB6 vs. VB.NET - Comparison
Visual Studio is what makes this stuff so nice. One baseline application is capable of handling half a dozen different modern languages. VB, C#, J#, just to name a few. I do kind of cringe at that last one, but it's in there.
For developing web pages, I can't even imagine doing it without VS. The GUI is pretty intuitive until you start hitting advanced features. Even then, it's not incredibly difficult. Local design is also wonderful with it, because of the precise control it give you. You can manage every little thing that happens with your project, and there are no real generic types. Everything is pinpoint precise, and it may make life a little more complicated, but in the end it's much more precise. .NET is also muuuuuch better at automatically passing variables from one type to another than VB6 could have dreamed of being.
Did I mention Intellisense and AutoComplete? Freaking awesome.
Re: VB6 vs. VB.NET - Comparison
Re: VB6 vs. VB.NET - Comparison
Geeezes... now I wish I hadn't wasted my time, sounds like you've already made up your mind. I hate it when people do that.....
-tg
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by techgnome
Geeezes... now I wish I hadn't wasted my time, sounds like you've already made up your mind. I hate it when people do that.....
-tg
Believe it or not, I have not made up my mind. It's quiet a quandary actually. I really wanted a tool that also works well with Excel to create high performance add-ins using ActiveX and/or native DLLs. VB6 fits that bill perfectly. However, as noted in the prior posts in this thread, I've noticed how MSFT is "pushing" everyone away from VB6 and into the world of .NET. And, third party vendors are coming out with terrific .NET components and add-ins. Indeed, MSFT has effectively stopped further improvements in VBA for the Office platform (hardly any new vba features in Office 2007 !), and is "pushing" everyone to use the .NET interopt libraries to build Excel-based applications. Most developers seem to be using C# for those efforts. In addition, the job boards seem to show about a 3:1 demand for C# developers vs. VB.NET'rs.
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by Hack
Thanks much. My keyword contained "vs." and that killed the search.
Interestingly, there was no mention of what would have happened to VB6 had Microsoft continued to support it. It appears MSFT is this huge gorilla, just pushing everyone in the same direction. Also, given the huge CHANGE in syntax from VB6 to VB.NET, anyone starting out that has even a smack of Java or C++ coding under their belts would be dumb not to go directly to C# IMHO.
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by Hell-Lord
I would just like to note that there is problems when dealing with arrays in Vb.Net ...
Care to explain please?
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by syswizard
... Also, given the huge CHANGE in syntax from VB6 to VB.NET, anyone starting out that has even a smack of Java or C++ coding under their belts would be dumb not to go directly to C# IMHO.
That depends - difference between VB.Net and C# is basically the syntax.
Since VS2005 release language (in .Net) became almost irrelevant.
But of course if you are more familiar with C++ (or Java for that matter) than VB then C# is more likely to be your choice.
Re: VB6 vs. VB.NET - Comparison
Moved this to the general developer forum!
Re: VB6 vs. VB.NET - Comparison
In the end the language's full potential, or the qualities that's supposed to make it ideal or advantageous for such and such, is not maximized anyway often because of lack of developers/analysts/programmers competent enough to do so. Settle for the real world questions... such as which does the company need and will get me a job in said company?
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by syswizard
2) C++ ? You meant C#, right ? Why on earth would ANYONE desiring a rapid application development language move to C++ ?
Languages aren't RAD, unless you're some kind of surfie. Development environments and libraries are what enable rabid development.
Quote:
Originally Posted by syswizard
3) Cobol reference: interestingly, I see the same problem with VB.NET as I saw with Cobol: TOO VERBOSE. Without Visual Studio, programming VB.NET would be a huge hassle and very unproductive. A similar example exists today with INI files vs. XML files. My gosh, XML sucks when storing a handful of important system parameters/values. With an INI file, you can instruct a user (in an emergency) to quickly edit the INI file and restart the app.
XML does suck for storing name/value pairs because that's not what it's designed to do. XML's for hieararchical, flexible, storage. Use what's appropriate. As for verbosity, well I agree, but that's subjective. People can prefer either VB or C syntax.
Quote:
Originally Posted by syswizard
4) OO vs. Procedural : certainly for some large projects, OO is the way to go....but what about speed of dev ? OO requires huge, up-front planning and design. And, OO is very design sensitive. If done wrong, you must throw it away and start over.....risky business indeed. Naturally, for large projects, a good OO system is much easier to maintain.
Yes, OO sucks. Live with it, it's trendy.
Well, it does have its place, although entirely OO systems are complete overkill and a waste of time/space/effort. .NET's best used as a part of a complex system, not the whole thing.
Quote:
Originally Posted by timeshifter
Visual Studio is what makes this stuff so nice. One baseline application is capable of handling half a dozen different modern languages. VB, C#, J#, just to name a few. I do kind of cringe at that last one, but it's in there.
For developing web pages, I can't even imagine doing it without VS. The GUI is pretty intuitive until you start hitting advanced features. Even then, it's not incredibly difficult. Local design is also wonderful with it, because of the precise control it give you. You can manage every little thing that happens with your project, and there are no real generic types. Everything is pinpoint precise, and it may make life a little more complicated, but in the end it's much more precise. .NET is also muuuuuch better at automatically passing variables from one type to another than VB6 could have dreamed of being.
Did I mention Intellisense and AutoComplete? Freaking awesome.
It says something about the framework that you list an IDE as its best feature. I'm always amused by this. :)
Quote:
Originally Posted by Hell-Lord
I would just like to note that there is problems when dealing with arrays in Vb.Net [...]
I don't think there are. What are the problems?
Quote:
Originally Posted by syswizard
However, as noted in the prior posts in this thread, I've noticed how MSFT is "pushing" everyone away from VB6 and into the world of .NET.
.NET makes them money; VB6 no longer does.
Re: VB6 vs. VB.NET - Comparison
We are moving away from VB6 into .NET (FINALLY!!)
However, the mandate from on high is that no existing application will be rewritten. All new applications will be done in VB.NET - existing apps will stay in Vb6, including any and all enhancments/upgrades.
Re: VB6 vs. VB.NET - Comparison
If you have ever used a MAINFRAME-type machine - we used Digital Vax-11's - then you will appreciate the framework.
Vax's had system libraries that offered complete control of every aspect of the environment - and was cross-language capable. Truly professional.
The framework is equivalent to this - a comprehensive and standard place to gain access to the environment. It's heavily typed - parameters are forced to be of a certain type - and consistent.
The IDE makes it effortless to use this incredible store of functionality. The intellisense with help tags right on the screen allows for very quick development against a huge array of functionality.
API calls from VB6 certainly weren't friendly (at least not to me!).
And OO or not - it's still your choice. We just developed a silly little Pocket PC app - it's a textbox, a label and two list views. There was no reason to go OO with this - it's 3 sub's to load data and half a dozen events. All in one form (although we did create a CLASS for setting APPLICATION PROPERTIES that writes to XML files - since the COMPACT EDITION of the FRAMEWORK was missing this functionality - couldn't help using OO concepts for this - it's good practice).
And I don't really agree that large projects using OO require huge amounts of up front planning. All large projects requires that - it's just easier to use Iterative Development techniques in a procedural app. Although it creates one crapping procedural app in the long run! I think that OO actually allows cleaner Interative Development as long as the initial requirements are understood.
As for the XML - there is great functionality in the framework for loading XML data and manipulating it. Without using manual I/O concepts. I'm not proponent of XML - but whether I store config data in an INI or XML file is truly irrelavent. Download XML Notepad from MS and see what it can do...
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by penagate
Languages aren't RAD, unless you're some kind of surfie. Development environments and libraries are what enable rabid development...
I'm afraid you're wrong - VS++ has the as you said "RAD environment", however it wasn't designed to handle RAD development.
VB was in my opinion first true RAD tool (language if you will).
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by penagate
Development environments and libraries are what enable rabid development.
Actually, that's what happens when you are bitten by a diseased programmer.
OO does not have to be embraced entirely. Use classes where classes make sense. Use procedural programming where that makes sense. You can have the best of both worlds. Doing otherwise is putting form over function, which is not a good idea in any design.
C# does seem to be the more popular language, but I'd say the two are so interchangeable that it makes little difference.
However, if you are going to write Excel macros, I believe that language is still VB6 based. Until that changes, you might as well stick with VB6. I much prefer .NET, but the syntax IS different between the two, so learning .NET when you have to remain in VB6 syntax in Excel hardly makes sense.
On the other hand, if you just want to write programs that work with Excel, you can do that fine in .NET. Interop is a minor issue in my experience. Kind of annoying, at times, but ultimately no big deal.
Re: VB6 vs. VB.NET - Comparison
Thanks all for the great responses....and good discussion.
I'd be interested in understanding the rationale for NOT converting existing VB6 programs to VB.NET when in fact it is done automatically by VS, correct ?
I mean if it was a huge manual endeavor, I could see why management would only do new dev in .NET.
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by Shaggy Hiker
Actually, that's what happens when you are bitten by a diseased programmer.
OO does not have to be embraced entirely. Use classes where classes make sense. Use procedural programming where that makes sense. You can have the best of both worlds. Doing otherwise is putting form over function, which is not a good idea in any design.
Quote:
However, if you are going to write Excel macros, I believe that language is still VB6 based. Until that changes, you might as well stick with VB6. I much prefer .NET, but the syntax IS different between the two, so learning .NET when you have to remain in VB6 syntax in Excel hardly makes sense.
On the other hand, if you just want to write programs that work with Excel, you can do that fine in .NET. Interop is a minor issue in my experience. Kind of annoying, at times, but ultimately no big deal.
Great post....but it is interesting to see how many programmers are reluctant to change....even with MSFT pushing them. Many great Excel VBA gurus are reticent to the point they say they would retire from coding if they had to migrate to .NET interopt.
I think for now, I'll stick with Excel/VBA with some help from VB6 for component development....but definitely look to migrate the app to .NET after the prototype has been built.
Re: VB6 vs. VB.NET - Comparison
I was VERY reluctant to migrate myself. I had both VB6 and .NET installed for about a year before I tried .NET. What finally got me moving was the need to write a program for a PDA. The .NET CF was so superior to eVB that I used it for that reason, and decided I liked .NET enough to try it. Now I would never go back willingly, even though I loved VB6 at the time.
Re: VB6 vs. VB.NET - Comparison
Here's a REAL INTERESTING move made by MSFT recently with the introduction of Office 2007: Excel DOCUMENT level security has improved to the point that it is no longer hackable. However, VBA CODE security was NOT improved even though it would have been easy to do.
This effectively "PUSHES" Excel developers to VSTO/.NET to create Excel apps that are "secure".
Pretty slick, eh ?
Re: VB6 vs. VB.NET - Comparison
Quote:
Originally Posted by syswizard
Here's a REAL INTERESTING move made by MSFT recently with the introduction of Office 2007: Excel DOCUMENT level security has improved to the point that it is no longer hackable. However, VBA CODE security was NOT improved even though it would have been easy to do.
This effectively "PUSHES" Excel developers to VSTO/.NET to create Excel apps that are "secure".
Pretty slick, eh ?
That's just good business sense for MS - in my opinion.
You introduce a new product phasing out an older product and want people to adopt that new product...
