Moving to VB.NET from VB6

[penagate]

If you don't say why, yours becomes only an offensive statement.

I did explain, it was in the part of my quote that you conveniently chopped off

[conipto]

That article you last quote seems to say "While we know it sorta sucks, you will have to do it anyways because M$ hath decreed it so." Isn't it better to convert things now when you have the time than later when you don't?

Bill

[esposito]

That article you last quote seems to say "While we know it sorta sucks, you will have to do it anyways because M$ hath decreed it so." Isn't it better to convert things now when you have the time than later when you don't?

Bill

The truth is, I am not convinced that .NET is the future. If billions of former VB6 developers decided not to upgrade, it means there are serious reasons for it and I think I have already pointed out some of them.

If you develop software for the general public, you can't take for granted that everybody has the framework installed on their machines. Now, distributing a 23MB runtime file is not easy at all. A customer who does not have an ADSL connection will never download it from the Web just to make your .NET app work. Very likely, he will switch to less problematic software.

The framework is the most important reason why I don't want to move to .NET. The second reason (vulnerability of byte-code) is less serious simply because you can resort to some good tools to obfuscate your code, but even so it is still a problem.

The last bad news I heard about is the fact that .NET Framework 2.0 is not backward compatible. So, if you have distributed some applications developed with VS 2003 now you have to provide your customers with another 23MB runtime file to allow them to use your new software developed with VB 2005. I'm sorry, it's more than I can bear.

[capsulecorpjx]

I agree. Besides, if it isn't broke (VB6) don't fix it.

The truth is, I am not convinced that .NET is the future. If billions of former VB6 developers decided not to upgrade, it means there are serious reasons for it and I think I have already pointed out some of them.

If you develop software for the general public, you can't take for granted that everybody has the framework installed on their machines. Now, distributing a 23MB runtime file is not easy at all. A customer who does not have an ADSL connection will never download it from the Web just to make your .NET app work. Very likely, he will switch to less problematic software.

The framework is the most important reason why I don't want to move to .NET. The second reason (vulnerability of byte-code) is less serious simply because you can resort to some good tools to obfuscate your code, but even so it is still a problem.

The last bad news I heard about is the fact that .NET Framework 2.0 is not backward compatible. So, if you have distributed some applications developed with VS 2003 now you have to provide your customers with another 23MB runtime file to allow them to use your new software developed with VB 2005. I'm sorry, it's more than I can bear.

[esposito]

The list of "inaccurate articles" seems to be endless. Here is another one:

Surveys by Evans Data indicate that the number of VB6 developers outnumber the people who have learned VB.Net. Forty-four percent of developers report working with VB, while 34 percent work with VB.Net--a percentage that has remained constant since the introduction of VB.Net at the end of 2002, according to Joe McKendrick, a research consultant with Evans Data.
[...]
The "carrot" Microsoft can use to entice VB6 developers to migrate are new features, such as the Avalon presentation system and Indigo communications being built into the Windows operating system, DeMichillie said. The "stick" is cutting off mainstream support, he said.

"There's not a huge difference between mainstream versus extended support," DeMichillie said. "But companies don't like it: It's a psychological milestone which says that the product is getting long in the tooth."

Source site:
http://news.com.com/Microsoft+walks+...tml?tag=st.num

[sevenhalo]

Fx = Firefox

It's also an abbreviation for Framework.

[sevenhalo]

Paraphrasing the article I mentioned above, I could say, "If .Net were secure and safe, MS would not be missing a billion dollars of upgrade revenue three years after the launch of VB .NET since VB6 users aren’t upgrading to VB .NET at all."

And aren't you the poster boy for this? Literally, asking people for reasons not to upgrade instead of researching .Net yourself?

I agree not all projects need to be updated, but alot can benefit. I'm only upgrading projects that I can incorporate into new development. For instance, if I'm building an internal purchasing system and our inventory system is in VB6; I'll upgrade the inventory system and make some changes along the way to optimize them for eachother.

I'm by no means prancing and skipping through the server room with high power magnents "ridding the company of evil legacy code." I just start all new development with the "what other projects can I incorporate?" question in the back of my mind.

[sevenhalo]

If you develop software for the general public, you can't take for granted that everybody has the framework installed on their machines. Now, distributing a 23MB runtime file is not easy at all. A customer who does not have an ADSL connection will never download it from the Web just to make your .NET app work. Very likely, he will switch to less problematic software.

You conveniently left out that Vista is being distributed with the 2.0 Fx.

The last bad news I heard about is the fact that .NET Framework 2.0 is not backward compatible. So, if you have distributed some applications developed with VS 2003 now you have to provide your customers with another 23MB runtime file to allow them to use your new software developed with VB 2005.

Just for clarity, they're a side-by-side Fx. Because of MS's new versioning system,, both can co exists and not interfere with one another.

23MB isn't that big of a deal when you think about it. Norton Antivirus' definitions files are around half the size and a new one is distributed about 4x a week. Plus, consider the alternatives. These "horrible 23MB files that are absolultely unbearable" is not a new $130 OS like it would be in the Mac camp. I bet they would kill to be able to download a file and ensure compatibility with Mac's future software.

[penagate]

23 MB @ 56k = a bit over an hour. I don't know why a customer would find that "problematic", system updates are routine - I've seen MUCH worse, and that includes critical fixes for Windows itself. SP1/2 on dialup, anyone?

Not to mention that the framework is on all sorts of application CDs these days, 1.1 comes with SP2 (a free disc for which can/could be ordered for free* from Microsoft), and 2.0 coming with Windows Vista. Plus, it is probably on countless PC magazine discs, and included with all sorts of hard-media-distributed software.

And - you only have to install it once (per framework version) - and it allows you to run ANY .NET applications... so the gain/loss ratio is infinite, in a way

* postage not included, AFAIK

[szlamany]

To sum up, these are the disadvantages of switching to VB.NET I have detected so far:

1. Difficulty in migrating legacy VB code to .NET.

Wrong - the CLR is all about a common place to code. The power of the CLR when it comes to cross-language work - SQL sprocs - it's almost overwhelming what an incredible job MS did in giving developers a suite of tools that are integrated - that's what you get from the largest software house on the planet

2. Deployment of the huge .NET Framework.

I also deal with school districts - 1000+ users on PC's of all era's. All these machines will have .NET framework for reasons other then my app's - which are VB6 now and going to VB.Net as quickly as we can go (probably 2 years...

3. Easiness of cracking and/or reverse-engineering a VB.NET executable.

Do you really, really feel that someone is going to steal an algorithm from you? I've been developing software for 30 years now - and I do think that I've had a handful of IT managers leave a site with my software in their back pocket - but reverse engineer? That seems like a paranoid feeling - not a reality feeling

4. Whenever the Framework version changes, you will have to upgrade your applications and provide the final user with the correct version. (Poor backwards compatibility)

MS has not become the poor backwards compatibility villian just because of the VB6-->VB.Net disconnect. That was a required step in order to embrace the CLR/framework. Not something they wanted to do - something they had to do - there was no choice. VB6 was based on 1970's concepts - it is not and never was a professional programming language - which is what .Net is now

5. Syntax is more complex in VB.NET than in VB6.

Syntax is actually more robust - not more complex

my take anyway...

[penagate]

Besides, if it isn't broke (VB6) don't fix it.

They aren't fixing it. It is no longer supported
In seriousness, .NET was not an attempt to "fix" VB6. .NET was an attempt to introduce a portable object oriented software platform, like Java was - except with a slightly wider target audience. VB.NET, while not a successor to VB6, is Microsoft's incarnation of Visual Basic as a .NET language.

If, and here, I stress, I am referring to anyone, your favourite language is VB6, and you loath .NET for whatever reason, and Microsoft because they did not make a successor to VB6 - then you have a pretty narrow minded view and that is not a desirable attribute in a developer. Learning new languages/platforms should come naturally - it's part of the job.

The list of "inaccurate articles" seems to be endless. Here is another one:

Are you looking for articles that slam .NET in favour of VB6, or attempting to construct an non-subjective view of the situation? If, as I believe you are, are simply striving to find more and more ways to make .NET look bad, without presenting both sides of the debate in order to form an objective opinion, then of course you will succeed. Equally, if you want to slam VB6 and glorify .NET as the future of coding - you may find endless ways to do so.

P.S., sarcasm, while humorous when mildly witty, is unhelpful to a cause such as this

4. Whenever the Framework version changes, you will have to upgrade your applications and provide the final user with the correct version. (Poor backwards compatibility)

MS has not become the poor backwards compatibility villian just because of the VB6-->VB.Net disconnect. That was a required step in order to embrace the CLR/framework. Not something they wanted to do - something they had to do - there was no choice. VB6 was based on 1970's concepts - it is not and never was a professional programming language - which is what .Net is now

Although I wholly agree, I believe Esposito was referring rather to new framework versions. In any case "poor backwards compatibilty" is not a valid point to make, since the two major versions of the framework that exist today can be safely used concurrently (as I and many others are right now) and you only need to ensure that the user has the version of the framework that your application targets. In addition, modifications to .NET 1.1 source code required in order to compile it for .NET 2.0 are very minor, if any. And as for what will happen in the future, that we can only speculate upon, and speculation cannot form the basis of a sound argument.

[esposito]

You conveniently left out that Vista is being distributed with the 2.0 Fx.

The 2.0 Fx won't let my apps written in VS.NET 2003 work. I love standalone executables so much that I avoid using OCX's in my VB6 apps. The idea of having to distribute a 23MB virtual machine (which becomes much huger after its installation) is something I can't accept.

Just for clarity, they're a side-by-side Fx. Because of MS's new versioning system,, both can co exists and not interfere with one another.

23MB isn't that big of a deal when you think about it. Norton Antivirus' definitions files are around half the size and a new one is distributed about 4x a week. Plus, consider the alternatives. These "horrible 23MB files that are absolultely unbearable" is not a new $130 OS like it would be in the Mac camp. I bet they would kill to be able to download a file and ensure compatibility with Mac's future software.

23MB is big if you consider that it's only the size of the setup file. Again, after the installation, the hard disk is deprived of hundreds of MBs.

[esposito]

If, and here, I stress, I am referring to anyone, your favourite language is VB6, and you loath .NET for whatever reason, and Microsoft because they did not make a successor to VB6 - then you have a pretty narrow minded view and that is not a desirable attribute in a developer. Learning new languages/platforms should come naturally - it's part of the job.

It's not a question of learning a new language. It's a question of depending on a huge framework that, very probably, is going to be updated at least every three years with little or no backward compatibility.

[szlamany]

I love standalone executables so much that I avoid using OCX's in my VB6 apps.

We also use as few dependancy's as possible - but you can't avoid a handful. Our VB6 app's require an install - just to get MDAC and MSFLEXGRID on the machine...

If you are really looking to produce a list that will convince your boss, I've not seen one sound reason yet - and I run a commercial software development house.

I've sat in "best practice" meetings with my customers where the requirement to support and embrace .Net and everything new from MS is simply unavoidable. In those same sessions supporting just MS SQL as opposed to foxpro and oracle and several other DB's is simply unavoidable. IT departments want as little in the silo as possible to support the whole operation - and the framework (even thought 2 are required right now) fits right into that picture.

Supporting 1000+ PC on a LAN requires that kind of thinking.

[szlamany]

It's not a question of learning a new language. It's a question of depending on a huge framework that, very probably, is going to be updated at least every three years with little or no backward compatibility.

That's not true - that's an alarmist reaction.

[esposito]

That's not true - that's an alarmist reaction.

WHY is it an alarmist reaction? I think it has already happened: Framework 2.0 broke compatibility with Framework 1.1. Do you want to deny it?

[esposito]

We also use as few dependancy's as possible - but you can't avoid a handful. Our VB6 app's require an install - just to get MDAC and MSFLEXGRID on the machine...

If you are really looking to produce a list that will convince your boss, I've not seen one sound reason yet - and I run a commercial software development house.

I don't even use MDSC and MSFLEXGRID to make my apps standalone. If you don't believe me, you can download some of my commercial software from

http://web.tiscali.it/espositopasquale

The most valid reason for me to convince my boss is the following, "Sir, VB.NET will not allow me anymore to produce standalone software to be used in our School's LAN, unless we install the Framework on the tens of workstations we have. But, if we did so, we would have speed problems with some of our old machines still using Windows 98."

[szlamany]

WHY is it an alarmist reaction? I think it has already happened: Framework 2.0 broke compatibility with Framework 1.1. Do you want to deny it?

Read this:

http://www.pcworld.idg.com.au/index....28;fp;2;fpid;1

There is also info on MSDN about it.

Things happen - back in 1985 Digital released a new version of mainframe BASIC and took away:

UNLESS X=Y THEN

they said it was an oversite - we lived.

[szlamany]

If you are writing app's that are supposed to run on Win98 machines then this thread seems pretty pointless.

We develop with new tools for new hardware and want to be cutting edge. Granted we have to support Win 2000 machines and Server 2000 and Server 2003 machines - but we don't support Win98 machines.

If that is a requirement of yours then I am not in your world and cannot comment.

[penagate]

WHY is it an alarmist reaction? I think it has already happened: Framework 2.0 broke compatibility with Framework 1.1.

Then explain why I have to absolutely squat to continue running my .NET 1.1 applications. The reason: .NET 2.0 does not interfere with with .NET 1.1 - so I don't HAVE to update my framework version to continute running all my .NET applications, as you seem to be implying. I am referring directly to this quote

Whenever the Framework version changes, you will have to upgrade your applications and provide the final user with the correct version. (Poor backwards compatibility)

When the framework is updated no-one has to do diddly. You can continue developing for the old version of the framework using your existing development tools. Users can continue running your applications using the same framework version. And since the .NET framework is likely to be around for a long time and heavily backed by Microsoft, you can bet that it will be included in just about every update to Windows as well - so you can safely develop for newer framework versions too.

And if we are talking about future versions, I will reiterate my point (above) about speculative argument.

I don't even use MDSC and MSFLEXGRID to make my apps standalone.

MDAC and MSFlexGrid are library components.

The most valid reason for me to convince my boss is the following, "Sir, VB.NET will not allow me anymore to produce standalone software to be used in our School's LAN, unless we install the Framework on the tens of workstations we have. But, if we did so, we would have speed problems with some of our old machines still using Windows 98."

Although the world has (thankfully) moved on since Windows 98, that is the best point you have made so far. However, unless your machines are absolutely ancient, they should handle the framework fine.

[esposito]

MDAC and MSFlexGrid are library components.

I know they are. But if you use them in your VB5/6 apps, you will have to distribute and register them. In other words, you wouldn't be able to place a single executable in a shared folder and make it work by means of a simple link on each workstation without any installation. That's what my apps in pure VB5/6 code allow me to do. And that's why I love VB5/6.

[szlamany]

I know they are. But if you use them in your VB5/6 apps, you will have to distribute and register them. In other words, you wouldn't be able to place a single executable in a shared folder and make it work by means of a simple link on each workstation without any installation. That's what my apps in pure VB5/6 code allow me to do. And that's why I love VB5/6.

No that's not why you love VB5/6 - that's why you love writing "extremely" lightweight non-dependant executables.

There is a huge difference.

We write SQL apps - we have to have MDAC installed. That's why we love MDAC - it gives us SQL access.

From what I can tell here - you do not want a framework - you didn't want it in VB5/6 (no dependacy's here!) and you certainly won't use .Net because of that requirement.

[esposito]

If you are writing app's that are supposed to run on Win98 machines then this thread seems pretty pointless. If that is a requirement of yours then I am not in your world and cannot comment.

I think I had already made it clear in one of my first posts in this thread:

My concern is that, since my school distributes software to other schools, if we use VB.NET we may have problems making our software run on some old machines which are equipped with Windows 98 or Me.

Normally, when we distribute VB5/6 applications, we only provide the final users with the exacutable and it works fine. We don't use any OCX libraries because most of our programs must run in a LAN and we can't install them on each machine.

[sevenhalo]

The 2.0 Fx won't let my apps written in VS.NET 2003 work.

It will let your apps work. You just need both Fxs.

Chances are, if they haven't used apps in 1.1 by the time Vista rolls out, they're not going to use 1.1 apps afterwards. If they do, it's because of poor development and planning from the software distributors.

The idea of having to distribute a 23MB virtual machine (which becomes much huger after its installation) is something I can't accept.

23MB is big if you consider that it's only the size of the setup file. Again, after the installation, the hard disk is deprived of hundreds of MBs.

Then so be it. If you can't accept it, don't use it. As far as my development system is concerned, I don't have it bogged down with a bunch of computer games, DVD images and MP3s. I have PLENTY of HD room and if they want to add a couple hundred megs (taking your word for it) that will include a GAC and JIT compiler that assembles only the objects my application is using, therefore saving me processing time; I welcome it. I'd happily give them 2 gigs to make it even faster.
--------------
All honesty, I hope they break compatiblity every 3 years. If it's compatible, then it's just revisions. If it breaks, it's something innovative. (Not to mention, it draws the line between developers and maintainers)

My car isn't compatible with both steam and fuel. Pretty soon, we'll have hydrogen cell cars that won't be compatible with fuel. Can I expect a similiar thread from you then?

[esposito]

No that's not why you love VB5/6 - that's why you love writing "extremely" lightweight non-dependant executables.

There is a huge difference.

We write SQL apps - we have to have MDAC installed. That's why we love MDAC - it gives us SQL access.

From what I can tell here - you do not want a framework - you didn't want it in VB5/6 (no dependacy's here!) and you certainly won't use .Net because of that requirement.

You hit the nail on the head. That's what I have been trying to say since the beginning of this discussion. I don't think you commit a crime if you want to develop lightweight non-dependant executables.

[szlamany]

You hit the nail on the head. That's what I have been trying to say since the beginning of this discussion. I don't think you commit a crime if you want to develop lightweight non-dependant executables.

With that said, you are unique - you could be writing in ASM if you want...

But you certainly are not a candidate for VS.Net - 2003 or 2005.

All of us are coming at you from different angles, but the bare facts are that none of what we are saying changes your "lightweight" requirement.

Does your boss embrace that as well?

[penagate]

You could tell your boss that you are unable to provide the same deployment efficiency and ease of installation when utilising the .NET framework, as you currently enjoy without that dependency. If you care to, you might mention the benefits of a language such as C++ which requires NO dependencies (VB requires the VB runtime library after all).

[Shaggy Hiker]

VB6 does have dependancies, there's still the runtime. I forget whether it was bundled into 98, but it sure wasn't bundled into 95. Is that dependancy acceptable because it is smaller?

The place I am coming from was that I was a HUGE fan of VB6, and used it for years, even after .NET came out. Eventually, I started using .NET for the CF (eVB pretty much sucks in comparison, it isn't even truly VB, but VBScript). I found that I liked .NET so much that I have no desire to ever go back. I don't even like maintaining the legacy VB6 programs I wrote.

My point is this: Be very very sure that you are being honest with yourself as to why you don't want to go to .NET. I am not alone in being reluctant to make the move, but having made the move, I have NO desire to ever go back, even temporarily. In short order in .NET, I found I was writing better, cleaner, code, and I was writing it faster. VB6 is awkward drudgery to me now. Many folks will not move to .NET simply out of fear of change.

Be very certain that is not your major motivating factor.

[capsulecorpjx]

Actually I know VB 6 has lots of limitations. And if you're starting a project, VB.NET is better to use.

I'm talking about the OP's application. If it is working fine as VB6, why port? Does no longer support means that in future Windows versions, they won't have the VBRuntime files as a basic install with the OS?

They aren't fixing it. It is no longer supported
In seriousness, .NET was not an attempt to "fix" VB6. .NET was an attempt to introduce a portable object oriented software platform, like Java was - except with a slightly wider target audience. VB.NET, while not a successor to VB6, is Microsoft's incarnation of Visual Basic as a .NET language.

If, and here, I stress, I am referring to anyone, your favourite language is VB6, and you loath .NET for whatever reason, and Microsoft because they did not make a successor to VB6 - then you have a pretty narrow minded view and that is not a desirable attribute in a developer. Learning new languages/platforms should come naturally - it's part of the job.


Are you looking for articles that slam .NET in favour of VB6, or attempting to construct an non-subjective view of the situation? If, as I believe you are, are simply striving to find more and more ways to make .NET look bad, without presenting both sides of the debate in order to form an objective opinion, then of course you will succeed. Equally, if you want to slam VB6 and glorify .NET as the future of coding - you may find endless ways to do so.

P.S., sarcasm, while humorous when mildly witty, is unhelpful to a cause such as this


Although I wholly agree, I believe Esposito was referring rather to new framework versions. In any case "poor backwards compatibilty" is not a valid point to make, since the two major versions of the framework that exist today can be safely used concurrently (as I and many others are right now) and you only need to ensure that the user has the version of the framework that your application targets. In addition, modifications to .NET 1.1 source code required in order to compile it for .NET 2.0 are very minor, if any. And as for what will happen in the future, that we can only speculate upon, and speculation cannot form the basis of a sound argument.

[penagate]

Actually I know VB 6 has lots of limitations. And if you're starting a project, VB.NET is better to use.

I'm talking about the OP's application. If it is working fine as VB6, why port? Does no longer support means that in future Windows versions, they won't have the VBRuntime files as a basic install with the OS?

The VB6 runtime library support period has been extended to cover the lifecycle of Windows Vista - until the end of 2008. Support for VB6 itself, on the other hand, ceased mid this year.

[esposito]

With that said, you are unique - you could be writing in ASM if you want...

But you certainly are not a candidate for VS.Net - 2003 or 2005.

All of us are coming at you from different angles, but the bare facts are that none of what we are saying changes your "lightweight" requirement.

Does your boss embrace that as well?

My boss must accept the fact that, if we don't change our ancient machines, we can just forget about .NET.

[esposito]

You could tell your boss that you are unable to provide the same deployment efficiency and ease of installation when utilising the .NET framework, as you currently enjoy without that dependency. If you care to, you might mention the benefits of a language such as C++ which requires NO dependencies (VB requires the VB runtime library after all).

Thanks. That's exactly what I am going to tell him.

[esposito]

VB6 does have dependancies, there's still the runtime. I forget whether it was bundled into 98, but it sure wasn't bundled into 95. Is that dependancy acceptable because it is smaller?

The place I am coming from was that I was a HUGE fan of VB6, and used it for years, even after .NET came out. Eventually, I started using .NET for the CF (eVB pretty much sucks in comparison, it isn't even truly VB, but VBScript). I found that I liked .NET so much that I have no desire to ever go back. I don't even like maintaining the legacy VB6 programs I wrote.

My point is this: Be very very sure that you are being honest with yourself as to why you don't want to go to .NET. I am not alone in being reluctant to make the move, but having made the move, I have NO desire to ever go back, even temporarily. In short order in .NET, I found I was writing better, cleaner, code, and I was writing it faster. VB6 is awkward drudgery to me now. Many folks will not move to .NET simply out of fear of change.

Be very certain that is not your major motivating factor.

The VB5 runtime has been included as of Windows 98. That's why I usually use VB5 to develop my applications.

As far as I am concerned, I have already downloaded VB 2005 Express and, over the next few days, I am going to "play" with it. Nevertheless, I will continue to develop my commercial software in VB5/6 for the reasons I have already explained.

[abhijit]

Hello, my boss is considering the idea of migrating to VB.NET. He asked me to do some research into the advantages of using VB.NET 2005 instead of VB6.

What can you do in VB.NET that cannot be done in VB6?

Any help will be appreciated.

VB .net (more pain less gain) especially if you are looking to upgrade an application that is full of spaghetti code. If your app is a modular one, then it wont create any major hassles. I am speaking from my own personal experience.

However VB 6 code will not run forever. One day it will stop. As far as I know Microsoft has stopped providing support to VB6. Its in the application graveyard. So future projects need to be planned on present technologies.

[Shaggy Hiker]

VB .net (more pain less gain) especially if you are looking to upgrade an application that is full of spaghetti code. If your app is a modular one, then it wont create any major hassles. I am speaking from my own personal experience.

However VB 6 code will not run forever. One day it will stop. As far as I know Microsoft has stopped providing support to VB6. Its in the application graveyard. So future projects need to be planned on present technologies.

Even if the runtime was no longer included in the OS, would that preclude being able to install it and use VB6 programs? I wouldn't expect that. Therefore, legacy VB6 code could become the next COBOL.

Upgrading hardware would be great.....but you talk about a school system, so it's hopeless.

[esposito]

Even if the runtime was no longer included in the OS, would that preclude being able to install it and use VB6 programs? I wouldn't expect that. Therefore, legacy VB6 code could become the next COBOL.

I don't know if, after Windows Vista, MS is going to deprive the OS of all the runtime files that a VB5/6 application needs to be able to run. As you know, the list is quite long and includes, for example, OLEAUT32.DLL which was a real pain in the neck when VB6 first came out. (It had to be installed on Windows 98 overwriting the version included in the OS.) In that case, installing a VB5/6 application would require quite a cumbersome setup package.

Upgrading hardware would be great.....but you talk about a school system, so it's hopeless.

That's one of the reasons for my disappointment with VB.NET: it is incompatible with my particular situation.

[esposito]

From http://classicvb.org :

Attention MSDN Subscribers!
On November 18, 2005, Microsoft announced Upcoming Content Changes that included the removal of Visual Studio 6.0, Windows 2000, and Windows NT 4.0 from MSDN Subscriber Downloads, starting December 16, 2005. The Sun settlement over Java was cited as the reason for this change in product availability. However, that excuse was used two years ago as well, so it's not entirely clear how it's now an issue again. Nor do they say on what basis they choose to leave VB6 available for download until June 30, 2006.

Do you know where your old MSDN discs are?

[billcoupe]

I've followed this thread with some interest.

I've been at this programming thing for 20+ years now, and the arguments not to migrate are always the same, existing hardware, bloated run times, learning curve, and so on.

One thing has held true over the past couple of decades. If you move forward, embrace new technologoes, languages and methods, you remain a desired commodity in employment terms. If you don't the demand for your services falls off, as does the pay rates you'll be offered.

In the days when a 10Mb HD cost around $1,000, there were plenty of reasons to write in languages that allowed for very small and light executables. Today with 200Gb HD's in the $100 range, that kind of thinking really doesn't make sense.

If you want your career to stagnate, don't learn anything new, don't take any chances, write to the least common denominator (Win 95 or DOS PC's) and spend countless hours defending your decision to do so.

On the other hand, if you want to open opportunities, continue to earn more money, and have your skills be in high demand, you must move forward. It's the price you pay to remain competitve in this business.

I for one intend to retire at the top of my game, not like some old 'COBOL' programmer churning out maintenance coding in my final working days. I'd like to retire right after I write the absolute best application I've ever written in a state of the art environment, for state of the art machines.

Just my .02.. YMMV

-Bill

[esposito]

To billcoupe:

Believe it or not, I agree with you entirely: embracing new technologies is essential to survive. The problem is, I doubt .NET represents the future as far as commercial software is concerned.

At present, deploying a 23MB VM is a big problem if you distribute shareware applications downloadable from the Web. The majority of Windows XP based machines are equipped with v.1.1 of the framework and not v.2.0. If you use VB.NET 2005, you can't ignore this issue.

Shortly speaking, .NET is not the ideal tool to use if you want to develop standalone software. If on the one hand it is true that .NET put an end to the DLL hell, on the other it is also true that it has introduced a worse problem: the framework headache.

I wish VB.NET was like REALbasic 2005 which generates standalone executables and allows you to produce software for Windows, Mac and Linux. As you can read on the company's Web site, RB is "cross-platform development that really works!"

You may object to what I say by pointing out that Windows Vista is going to be shipped with Framework 2.0 pre-installed. Unfortunately, for the time being, Windows Vista is not on the market yet and the framework hell is something you have to cope with

[Hack]

To billcoupe:

Believe it or not, I agree with you entirely: embracing new technologies is essential to survive. The problem is, I doubt .NET represents the future as far as commercial software is concerned.

It certainly doesn't as far as my company is concerned, and that is not because anyone has anything against .NET

In fact, we have .NET versions of all of our base products, and to date, none have sold. In fact, we only have two customers who have even expressed an interest in seeing a demo of our .NET versions.

All off our products that are being sold continue to be our VB6 versions.