Future versions and developing...

Hello,

I am a software developer for a global company. Our current HMI is written in Visual Basic 6. We tried converting to dot.net when Studio 2003 came out. Then...2005 came out...and now there is 2008. The change has been rapid and the changes from verison to version seem to be more than minor. Where does it end...or when will we see a stable version with only minor changes? I have heard rumors (not only here at my company) but on the Internet and companies not even going to dot.net because of the major changes from version to version and the extra memory costs....not mention performance problems.

Thanks!

birthjay, while I am sure someone from the MS team can chime in and give even more info, here are some important data points to consider:

.NET 1.1 (VS 2003) was the first major revision to the initial .NET release and was (IMO) the first .NET version that people got really serious with developing for.

.NET 2.0 (VS 2005) was a major improvement in many IDE related features as well as many syntax and language features. While there were some changes to consider when moving a project to 2.0 from 1.1, it was for the most part a pretty painless procedure.

Now of course we have .NET 3.5/VS 2008. One of the really nice features that is new to 2008, is the ability to backtarget past frameworks, but still use the 2008 IDE. This makes it easy to utilize the new IDE and its features, without forcing your projects to be upgraded past .NET 2.0 at the present time.

.NET 3.0 and 3.5 are built off of the core libraries of .NET 2.0, which is part of the reason they can offer this type of functionality.

Migrating applications to newer framework versions is also much less of a task than the initial migration from VB6 to .NET.

Birthjay -

I'm going to step in also and make a few comments. Again -Microsoft folks can correct me if they want.

The versions of Visual Studio that Microsoft has released have all been relatively stable. I've considered them as stable as most software. This includes 2003, 2005, and 2008. If someone says they are unstable, then ask for specifics because I'd like to know the issues too.

New versions of software is simply a result of evolution and adapting to changes in technology. Before Visual Basic 6, there was Visual Basic 5? If a software product could be released that did everything everyone could possibly think of for the future, and did it as easily as possible, then yes, there would be no need for new versions. That day has not yet come, nor is Visual Studio 2008 going to be the last version.

Does making it easier to code or adapting to provide functionality in the tool to tap into new technology make a product unstable? Build a Web site with Visual Basic 6 and build one with Visual Basic 2008. The amount of code that is required in the '08 version is going to be a lot less and the tools for dragging and dropping and creating the functionality are going to be a lot more powerful. That is evolution.

Yes, newer versions often require more memory and better hardware support. Having said that, the reason for these requirements is often a direct result of the functions that the new tools give you. There is a cost, but the return on the investment is higher productivity once you know to use the tool.

Why do new models of cars come out every year? To get you to buy them is the real answer. But why do people actually buy them? New features, smoother rides, better gas mileage, etc. Of course, you can keep driving your 1983 Ford Pinto, but don't be surprised as if you need wire to hold on your bumper and if you use more gas than others. Of course, if all you do is drive around the block, then that might be okay. :)


In Visual Basic 6, use the IDE to create a Pocket PC application. How hard would that be? Or can you do it? Try creating a Web site with VB 6. Add some Javascript. How is the intellisense help with that JavaScript? It is good in VB 2008. How about debugging? Can you debug across your VB desktop and code into the JavaScript or within a mobile application? These are just a few minor nitche examples of things that are in the newer versions. To go back to my analogy, these are things a Ford Pinto can't do. ;)

Brad!

All good points of course...but...I just want to point out that this application is 40,000 lines plus. This is the core of our business and certainly not Microsoft's problem ...... but there is a big issue for large and medium companies in regards to upgrading to "keep up". Our software is the HMI for $100,000 plus machinery. To "keep up" we have to devote quite a bit of time in development...especially between VB6 to the early version of .NET. Show me time studies on converting large apps from VB6 to .NET. Then show me the time study from converting from 2003.NET to 2005.NET...then to 2008.NET. We all understand the "new car" concept. But...what is the cost effectiveness from a companies point of view of having to redevelop every two years? Right now...our VB6 developed app still works great! How many years has it been since VB6 came out?

Birthjay, it sounds to me like this is something you could make use of, to move your app to .NET overtime, without going through the major process of a total rewrite, or using a conversion utility.

Interop Forms Toolkit 2.0
http://msdn2.microsoft.com/en-us/vbasic/aa701259.aspx

Continue to maintain the application in VB6 for the time being, but as NEW elements of the application are added, do them in .NET and intergrate them into the VB6 project. This would help move the codebase overtime to the .NET platform.

Good points on migration/cost/etc. The Microsoft folks might be able to address some of the things that were done with the 2005 release. I know there was an emphasis at that time to help make the migration from 6 to .NET easier.

I have also heard a number of Microsoft people (other groups) advise the same thing kleinma suggested.

This topic is a little off the main focus that we wanted for this forum, but we can see if the VB team wants to add anything.

Brad!

Hi-

I definitely hear your point that change needs to be gradual & incremental. It isn't cost effective to keep rewriting code to get back to functional equivalence.

From VB6 to .NET, I agree Interop Forms Toolkit is a great example where you can prioritize where you want modern features, create those new features, and drop them back into your existing code. The idea is to "embrace and extend" the app so you don't need to do a forklift style migration.

The changes between 02', '03, '05 and '08 are much smaller in scale than VB6 to .NET. Each version we add a few major platform innovations (generics, My, LINQ) -- and they were built to work with existing code. You can simply opt in or out of them every release. I would not recommend rewriting code to use them unless you have business need.

Also, we added multi-targeting support in '08 (i.e. you can now use the new tool to target .NET 2.0, 3.0, 3.5, and future). The great thing here is you can upgrade your VS version to get tooling benefits (faster performance, better intellisense, better lifecycle tools) without having to upgrade to the new version of .NET. You can also buy into a particular version of VS (let's say '08) and be happy running on it for a while. You have the choice to upgrade developer by developer or project by project.

I hope this addresses some of your concern. I realize MS is still innovating at a fast rate and there will be an impact on you despite our efforts to mitigate the costs/pain.

Thanks,
Paul

Quote:

---

Originally Posted by birthjay

All good points of course...but...I just want to point out that this application is 40,000 lines plus. This is the core of our business and certainly not Microsoft's problem ...... but there is a big issue for large and medium companies in regards to upgrading to "keep up". Our software is the HMI for $100,000 plus machinery. To "keep up" we have to devote quite a bit of time in development...especially between VB6 to the early version of .NET. Show me time studies on converting large apps from VB6 to .NET. Then show me the time study from converting from 2003.NET to 2005.NET...then to 2008.NET. We all understand the "new car" concept. But...what is the cost effectiveness from a companies point of view of having to redevelop every two years? Right now...our VB6 developed app still works great! How many years has it been since VB6 came out?

---

Allow me to use the adage: If it ain't broken, don't fix it. One shouldn't be upgrading software just because a new version is out. The VB6 to VB.NET 1.1 migration made sense, but if there are no compelling reasons to move to 2.0, then the effort is wasted, never mind the cost.

We have software made in VB4, VB5, old old OLD ASP applications, but newer development is done in 1.1, 2.0 and soon 3.5. Out of these, just one application had to be rewritten for a newer version of the language. This way, development time isn't wasted, and you get to do newer things.

Quote:

---

Originally Posted by birthjay

Hello,

I am a software developer for a global company. Our current HMI is written in Visual Basic 6. We tried converting to dot.net when Studio 2003 came out. Then...2005 came out...and now there is 2008. The change has been rapid and the changes from verison to version seem to be more than minor. Where does it end...or when will we see a stable version with only minor changes? I have heard rumors (not only here at my company) but on the Internet and companies not even going to dot.net because of the major changes from version to version and the extra memory costs....not mention performance problems.

Thanks!

---

Birthjay,

Here's my take on this situation. Convert your application to .Net or any other platform when it makes business sense to do so, and not before. Evaluate the additional capability (if any) that you are trying to add to your application and let that make your decision. Trying to take it to the Web? Then, yes, .Net would be the way to go. Is the application strictly Windows desktop and are you planning to keep it that way? If the answer is "yes" then don't convert to .Net just because it's the "popular" thing to do.

The thing that irritates me, sometimes, about this industry is the attitude that YOU MUST UPGRADE. That ain't necessarily so. If your application runs solid and your investment is better spent NOT porting the application then DON'T. Don't get hung up on tools - use the one that's best for the job. If VB6 is still the best tool for the job within your context then don't let "peer pressure" force you to do something else right now. Yeah, if you're going to develop a new web app then it would be stupid to stay with VB6, however if you're still developing desktop applications you won't kill yourself sticking with what you have become proficient with either.

That's my 2-cents.

-Max :D

Quote:

---

Originally Posted by Max Peck

...Yeah, if you're going to develop a new web app then it would be stupid to stay with VB6, however if you're still developing desktop applications you won't kill yourself sticking with what you have become proficient with either.

---

What would be a best guess on timing to completely abandon VB6? Any insight into future O/S support for the runtimes?

Quote:

---

Originally Posted by LaVolpe

What would be a best guess on timing to completely abandon VB6? Any insight into future O/S support for the runtimes?

---

That's hard to say, really. Five years? Ten? Longer? Though Vista has a few small issues with VB6 installations (related to the UAC and install routines I think) the runtime itself is still fully supported. (In other words, your target platform is still something like a billion PC's eh?) I took our application which still has huge sections of VB6 code in it and it ran unmodified under Vista - so there's little danger of it not being deployable in the forseeable future.

Even though Microsoft has abandoned VB6 (some call it 'classic' VB) support as far as making enhancements and bug-fixes to the product itself, it's pretty obvious that they don't intend to completely alienate the installed-base. I mean ... let's face it, there are billions of lines of tested and reliable code (and thousands-and-thousands of applications) written in VB6 technology. Companies (particularly smaller ones who can't afford to just order a rewrite of a 200,000 line application with the stroke of a pen) take a dim view of having to completely retool something that works without darn good reason. Being forced to do this could force many smaller companies out-of-business. It's expensive to rewrite code, particularly when it's pure overhead. (I.E. the rewrite doesn't add new functionality - it just maintains existing capability).

I think what we have here is perception vs. reality. The "perception" is that "everybody" is going to .Net. The "reality" is that there's a huge base that are either too strapped to make the move, "on the fence" or simply don't see the point right now. The larger companies (like the one I work for) who have large budgets can afford to just "rewrite" functioning applications just because it's "fashionable". Having said that, though, even our organization has been "talking" going to .Net for years; but we still have huge subsystems that are too customer-critical for us to just sit down and rewrite the thing all at once. The subsystem I maintain in VB6 could take a year or more to rewrite - before even thinking about added functionality. It's very complex.

What I tell new developers is this. If they're just entering the field, starting out - then definitely go the direction of .Net. No point in STARTING with the older stuff. However if you have an installed-base then the decision needs to be more of an economic and practical one. If your application sells well, runs fine and it makes sense to keep maintaining it in VB6 then do so. I have yet to have a client ask me what tool I used to produce their code - they just want it to work. Whether it's .Net or VB6 is irrelevant as long as the job gets done well.

Make sense?

-Max :D

Max, makes sense, but if Microsoft works like the government, then commonsense may not be the driving factor.

Another issue is DLL compatibility. Not only runtime dlls, but O/S dlls. Obviously if backward compatibility isn't fully supported on new O/S, then might as well say that runtime dlls will be indirectly un-supported too, since they very well may be relying on those older dlls via API calls. Making it more interlocked is support for dlls that manage subclassing, memory managment, IPC, and others that could prove to make future O/S systems vulnerable to attacks should they be supported.

I have no idea what your relationship to Microsoft may be, but if none, it would also be nice to hear from someone that may have insight to development of future O/S and the backward support expected.

Good points above.

Here's my take as the person in charge of VB6.
- Now is the time to do new development in .NET (both apps, components, and features added to VB6). You'll have the best experience and support path this way.
- Now is the time to think about a migration plan for your priority VB6 assets. If you move you should still do it gradually and incrementally.
- MS supports the VB6 runtime and hence your existing applications and components. The runtime shipped in Vista (supported through 2017) and will ship in Windows 2008 Server (supported through 2018). There is no urgency to abandon your existing VB6 apps. They will continue to run just fine, and MS is on the hook to fix breakers MS causes.
-The VB6 IDE goes into custom support April 2008. If you still want support for the IDE you / your company should consider purchasing a custom support agreement. The IDE will continue to run but you can't expect the same level of enhancements or bug fixing anymore.


To summarize, it's in situations where there is business need to enhance the app or use mainstream supported tools that you should strongly consider a migration. Migration should be done gradually and incrementally (using interop). It's ok to leave apps and components running on VB6 -- that's supported for 10 years. I expect to be supporting VB6 developers for years to come, and I welcome that opportunity.

BTW: our best VB6 & VB6 migration/interop content is here -- http://msdn.com/vbrun/

hth,

Paul

Quote:

---

Originally Posted by LaVolpe

Max, makes sense, but if Microsoft works like the government, then commonsense may not be the driving factor.

---

LOL! Good point!

Quote:

---

Originally Posted by LaVolpe

Another issue is DLL compatibility. Not only runtime dlls, but O/S dlls. Obviously if backward compatibility isn't fully supported on new O/S, then might as well say that runtime dlls will be indirectly un-supported too, since they very well may be relying on those older dlls via API calls. Making it more interlocked is support for dlls that manage subclassing, memory managment, IPC, and others that could prove to make future O/S systems vulnerable to attacks should they be supported.

---

I guess it all depends on how deeply your application is working with the system. If the runtime is fully-supported and your application still works then that's probably not something to worry about. However, that's certainly up to you. As an application developer I'm not all that concerned as to whether or not the low-level metal interactions work the same way as long as my application continues to get the same results. If you want to micromanage the relationship to the platform that's up to you. :)

Quote:

---

Originally Posted by LaVolpe

I have no idea what your relationship to Microsoft may be, but if none, it would also be nice to hear from someone that may have insight to development of future O/S and the backward support expected.

---

My only "relationship" to MS is as a customer of their products - nothing more. I don't own any of their stock or have any kind of torch of theirs. Just have been developing to their platforms since they have existed, that's all.

-Max :D

Quote:

---

Originally Posted by PaulYuk_MS

To summarize, it's in situations where there is business need to enhance the app or use mainstream supported tools that you should strongly consider a migration. Migration should be done gradually and incrementally (using interop). It's ok to leave apps and components running on VB6 -- that's supported for 10 years. I expect to be supporting VB6 developers for years to come, and I welcome that opportunity.

---

Now that's the Microsoft that I know. Thanks Paul.

-Max :D

Quote:

---

Originally Posted by Max Peck

I guess it all depends on how deeply your application is working with the system. If the runtime is fully-supported and your application still works then that's probably not something to worry about. However, that's certainly up to you. As an application developer I'm not all that concerned as to whether or not the low-level metal interactions work the same way as long as my application continues to get the same results. If you want to micromanage the relationship to the platform that's up to you. :)

---

I can buy that. At a worse-case scenario, a low-level, API-dependent, routine may need to be re-written/modified to handle specific situations on the newer o/s. And if that proves impossible due to new security settings or incompatibility, then would be a good time to lobby for pushing towards top of the list for faster app migration.

Quote:

---

Originally Posted by PaulYuk_MS

Good points above.

........ I expect to be supporting VB6 developers for years to come, and I welcome that opportunity.

BTW: our best VB6 & VB6 migration/interop content is here -- http://msdn.com/vbrun/

hth,

Paul

---

Thanks for all the posts. I think product support ended on March 31st, 2005 for VB6. ....But I am glad to know there is still help out there.

http://msdn2.microsoft.com/en-us/vbrun/ms788707.aspx

Thanks!