[RESOLVED] Conversions...

[RhinoBull]

I’d like first to express sincere "Thank You" to Brad and VB Team for this fantastic opportunity.

Here comes the question:

many of my clients are asking basically the same thing: how difficult or perhaps painfull is the upconversion process?
As we all know millions were invested in VB5/6 and even VB4 32 bit.
Any of the available conversion tools don't offer smooth process - in most cases re-writing is the only option.
So, my question is: "Is there anything in-the-work that would make conversions as easy as it can possibly be?"
We all love new features and the power of VB.Net however without powerful conversion utility many businesses may stay away for another year or so and we will have to maintain the legacy apps for much longer.

Thank you.

[funkyonex]

Hi there -- great question!

As you know there's a lot of things to consider when migrating or even upgrading any software system. And many times a full rewrite is not cost effective or really even necessary because the system is solid and working, it's just old and getting cumbersome to maintiain, or lacking features because there's no easy way to implement them in the older codebase/platform.

This is when taking a phased migration strategy may be in your best interest. If your system is VB6 and you're looking to start implementing VB.NET, then you should have a look at the Interop Forms Toolkit. This is a toolkit released by the VB team that allows you to write .NET forms and User Controls and use them directly in your current VB 6 applicaitons. This means you can rewite pieces at a time and still have a functioning application. Or you can use it to add new functionality that would be difficult or impossible to do in VB6 like add multi-threading support or call WCF or Web services.

Here's some How-Do-I videos to help get you up to speed, as well as some additional resources and blog posts from the team. You can also check out the Visual Basic 6 site for more information on developing hybrid applications as well as the Visual Basic Developer Center.

HTH,
-B
Beth Massi, VS community

[RhinoBull]

Thanks for your reply.
I am familiar with most of currently available technics - unfortunately none of them provides one solid solution which is the problem for many legacy shops that are willing to migrate their development environment to new platform.

Thank you.

[techgnome]

First, I'd like to echo the thanks of the others. I think this could be a terrific opportunity for everyone to learn why something are the way they are, work the way they do, or don't work as expected sometimes. I think this will also (hopefully) help people to understand that people at Microsoft really do care about the VB developers.

And now onto my comment/question.
Just out of curiosity, does that provide an advantage rather than going the other way? What we did was to rebuild our container portion of the app in .NET allowing it to host our VB6 user controls. Granted, it's like putting lipstick on a pig. Underneath, it's still a pig... but man, does it look 100% better!

The reason I bring this up is because it seems that the toolkit is referenced like it is the only solution, when it's not.

Now, this is where I come clean and describe our architecture, and ask if that's the difference that makes what we did possible. First, the main form of the app is an MDI parent (referred to as the App Console), which also cosists of two chile forms, both empty (one is used for custom dialog screens, the other for the "normal" screens). when a given screen is requested, it's program ID retrieved (ala a Controls table in the database), the UC is then created and added to the form. The form is then resiszed to the control (or the other way around, depending on the settings), and displayed to the user. What we did was to build a new App Console in .NET, and use it to host both the VB6 and newer .NET forms for new projects.

But then, it maybe the architecture that allows us to do that. Had we gone the other way with it, as per typical recommendations, I think we'd still be fighting problems.

-tg

[funkyonex]

Well, there really is no "one size fits all" approach to migrating or upgrading any software system, no matter what technology you're moving from really. You need to take a look at the architecture of the application and the state of the business to see what makes sense. For instance sometimes an "off the shelf" replacement is appropriate. Sometimes the codebase is so bad and the business requirements have changed that a complete rewrite is in order. Other times a phased migration strategy is better. In that case you need to look how the application is designed to formulate the best approach. For instance, if you already have an n-tier design you can take a "horizontal" migration strategy where you replace a layer at a time, like the presentation tier. If you're dealing with a traditional client-server system with no separation of layers but you can draw lines between semi-independent "modules" of the system, then those isolated parts are great candidates for a phased upgrade. This is a more "vertical" approach. Using the toolkit will help you in these situations.

HTH,
-B

[funkyonex]

Hi tg,

It's definitely not the only approach. The toolkit just makes what you did easier by handling the plumbing for you. You can share application state, raise events, and expose properties and methods via COM interop with the toolkit. It's a set of templates and a library that makes your life easier. :-)

HTH,
-B

[chrislong2]

Hi Beth,

I too want to echo my thanks to you and the VS team for being willing to come in here and address some of our questions and concerns.

I do have some questions and concerns that I would like to ask you along this line of converting from VB6 to .NET. I'll tell you upfront that I'm going to be direct and I hope that you (and nobody else) takes any offense - I believe my thoughts are ones that many echo and are concerned about.

1) The poster above hit one of the major points which is the difficulty in migrating from VB6 to .NET because of the code re-write involved. At the end of the day, the issue is that one still has to re-write much of their code (whether done in stages using interop or not). I do thank you for the Interop forms - they are very helpful in aiding in this process! However, as mentioned above, if there really could be a better conversion tool - this would help greatly. So, I guess I ask you bluntly: Isn't there more that Microsoft could be doing to help people like me convert all my code to .NET?

2) There is a more fundamental issue in all of this that is a concern of mine and that I know is a concern of many though some probably won't vocalize. I am a longtime Basic programmer (back to QuickBasic). When I moved to VB 3 (and subsequently 4,5,6) it was an easy move because essentially the language was the same. The main issues were primarily the GUI/forms/event-driven model. But it was easy to see how it extended the Basic language, complemented it if you will. VB .NET is fairly different though. When Microsoft went that route, I was and am okay with it. But it also meant that because Microsoft made that decision that many people who had just built/supported their entire businesses on VB 6 (or 4,5) code had to change. This meant and still means a lot of man hours and money involved, whether it is done all at once or over a period of time.

My concern is, again quite bluntly, if I take the plunge and spend my time and money to convert my code to .NET, what guarantee do I have that 2 years from now Microsoft won't decide to majorly shift courses again, resulting in me again having to spend lots of time and money? I know that is a hard question for you to answer. And in all honesty, I know you probably can't. But I must tell you that it is chief at the top of my list of my concerns/questions. For mega-corporations with huge IT budgets, this isn't as big of a concern. For the small business owner or individual developer, this is a HUGE concern. If I'm going to lay out more money and time to devote to .Net, I want to have some sort of realistic guarantee that my apps will function for many many years on future OS's without having to worry about needing to completely change it all again.

This is why I am and have been watching how MS has been treating VB6 so closely. So far, in my opinion (I know others disagree), MS has been reasonable with its VB6 support and the runtime (and IDE) is still supported on Vista ensuring that VB6 programs still run (in my way of thinking since VB6 is 32-bit it ought to be supported on all 32-bit Win OS's). This is very important as I have and would expect this from MS. As long as MS continues this approach of pointing to .Net but still supporting their earlier tools, you will win me over - I guarantee it. But if all of a sudden MS just drops native support for my current VB6 programs on future 32-bit OS's, etc. that just helps to reinforce my concerns, etc. As I've said, I think thus far it has been reasonable.

But then I think about what happened with WinHelp/HTML Help. Many many programs used WinHelp. When Vista came out, WinHelp support was removed from the OS so that all of these programs had to have their help converted to HTML Help (not necessarily an easy task, either). I personally had to spend many many many hours doing this just because MS decided to end support for what was an extremely common format. I know many other developers in a similar boat. I know the reasons that MS gave (and I didn't agree with them since by far, HTML Help has had far more security problems than WinHelp EVER did). You may say what does WinHelp have to do with .Net, and I'll tell you: "everything". Because it was just one more thing to make me really really nervous about devoting large amounts of resources to what MS says is the best way to go, only to possibly find out a few years from now that it was largely in vain because MS has a new vision and drops support for its previous endeavors.

.Net and the managed code approach definitely has its place. But there are also plenty of apps (think small business owner/individual programmer as opposed to mega-corporation) that could be created in VB6 just fine in an unmanaged approach. Although I probably will end up moving more heavily into .Net, I also don't like anyone (MS) telling me that I "have to or else". Or that I'm somehow "lesser" because I have chosen not to go the .Net approach thus far.

My point is I would encourage you all to continue to try to make the transition to VB .Net even easier and point out its strengths. But at the same time, I would encourage you not to take the heavy-handed approach of trying to force VB6 users to .Net. I could be wrong, but I believe that would backfire in the end.

Thank you for your time. I do have one positive comment to make to you as well: I believe that the free "Express" VS editions were a very smart move to help in this process of helping people see .Net and its abilities. Again, for the corporations this doesn't matter so much. But for the casual developer or small business owner, this is the type of thing that is very helpful. I would encourage MS to try even more to win over this demographic instead of focussing so highly on just the corporate setting. This demographic is large and ultimately also impacts the corporate setting.

Thanks,
Chris

[funkyonex]

Hi Chris,

Let me try to answer some of your concerns to the best of my ability based on my experience in the industry. I have a similar story, though a tad more "challenging" I suppose depending on how you look at it . I'm speaking from experience outside of Microsoft so bear with me as I take a walk down memory lane.. so here it goes.

I originally started programming (for money) in Clipper then FoxPro (DOS and Windows. Yes I know this is probably dating me but let's ignore how old I am .) When Visual FoxPro came along in 1995-ish it was object oriented which meant it had new designers, a new programming model, and a paradigm shift. One thing that FoxPro did do was try to support backward compatibility so that you *could* compile previous versions of Fox code in Visual FoxPro if you needed. You would think that being able to just compile and run your old codebase would be the perfect solution.

The problem was though that in practice we went through and re-wrote these systems piece by piece anyway because of the new more maintainable OOP programming model and what the new version gave us in terms of new features. Not to mention the new productivity tools and the new designers that did not work with the old code for screens and reports. How do you write a conversion tool to take functional code and convert it to OOP code? You really can't. Moving from a purely functional language to an OOP language was not trivial and there were a lot of people in the community that chose not to move, at least not right away. There was also a lot to learn. But once you DID start your phased migration, the new parts of the system were so much easier to work with.

Was it a bad decision to move FoxPro into the realm of modern programming and create an object oriented programming language? At the time you may have had many people answer yes to that question. But if you talk to anyone in the FoxPro community today that faced these challenges there will be an overwhelming number of people telling you that they are very happy that they moved to Visual FoxPro, even if it was painful, because moving forward they were on a more solid technical footing as well as having much more maintainable object oriented code with new productivity tools.

Of course, then came .NET. What was a FoxPro programmer to do? No conversion tools from Microsoft, no new language on .NET. FoxPro on .NET was called Visual Basic.NET . We needed to strategize on how/if we were going to migrate. You see, any technology, not just Microsoft, moves forward FAST. It's never going to stop. It's up to us as architects and software developers to make sure we design more agile systems, learning from our previous designs that failed. It's also up to the vendors, including Microsoft, to provide more agile tools that allow us to move forward. And remember sometimes the best choice is to buy an off-the-shelf replacement or not upgrade at all. I sometimes look at the problem in a similar way you shop for a new computer. Why would you ever buy a computer at all if the one you get is going to be $1000 cheaper a year later? Why would you buy a computer at all if there will be a much better one at the same price a year later? Because it solves a problem now and will continue to do so for a while, not forever, but for a while -- and that's worth the cost.

So once we decided it was necessary to move the application forward, I learned Visual Basic.NET and started planning the re-write. (I wish the toolkit was around back then because it works with VFP too ) This time though I was going to architect this system the "right way", with a componentized and layered design. You see old systems are so darn hard to migrate because they are not properly layered, componentized and loosely coupled. Picking a horizontal or vertical migration relies on how the components of the system fit together. If everything is in one layer it makes rewriting "pieces" almost impossible.

I understand that there has been a lot more than "normal" software innovation coming out from Microsoft recently and it really is overwhelming, even for me! I think a lot of that has to do with .NET providing an easier platform to create these innovations as well as the transparency the company has now -- like releasing CTPs and talking about research projects openly that may never make it out. It makes us excited and overwhelmed and cautious at the same time. But in general, I believe the openness to be a good thing and aids in software planning.

Software is getting easier and easier to build but more and more complex. The best approach that has worked for me was to not get too ahead of myself, keep a layered and componentized design to everything I write that needs to move forward, and work with the tools I am given to make my life easier (especially if they are free ).

I hope I addressed your concerns. Others from the team will likely also comment as this is a topic that is very forefront in our minds. Here are some references to help you in your migration journey.

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

Power Packs
http://msdn2.microsoft.com/en-us/vbasic/bb735936.aspx

PAG Migration Guide Book & Assessment Tool
http://msdn2.microsoft.com/en-us/library/aa480541.aspx

“Upgrading VB6 to VB.NET” MS Press Book
http://www.microsoft.com/mspress/books/5699.aspx

VB6 Code Advisor Tool
http://msdn2.microsoft.com/en-us/vbasic/ms789135.aspx

[chrislong2]

Hi Beth,

Thank you very much for your reply.

I do understand (and largely agree with it). Contrary to what my original note might have said, I do understand the need to continue the innovating process. Nothing is going to stay the same and I do understand that. Even .Net itself continues to evolve. This is all fine and to be expected. My chief concern along these lines though is that Microsoft ALSO has an obligation to their customers to support their earlier initiatives. My concern with Microsoft is that at every new turn there is a "new, recommended way" of doing something and another technology becomes "deprecated". Then there's fear that Microsoft could, at any time, remove support for that "old way". As you mentioned, being inside of Microsoft it can be hard to keep up. Think about the poor sap like me who doesn't work in Microsoft - it can be very difficult to keep up with every new twist and turn. Even .Net (I am not up on 2008 yet, so this may not apply) is not natively geared to take advantage of many of these newer, emerging technologies.

My point is that I have no problem with Microsoft continuing to innovate. I expect that. But I also expect that with each new innovation, the old way isn't just immediately dismissed or support withdrawn. Especially when millions of users are involved as the case was with VB6. With VB6, I expect that my 32-bit VB6 programs will always run on a 32-bit Microsoft OS with native support. This has thus far been true up to and including Vista. I expect it in the future as well. I also expect that .Net 1.0 and 1.1 continue to be supported, etc.

My fear with .Net is the fear over Microsoft dropping support one day after I've done all my converting, etc. See, as mentioned, Microsoft has done pretty decent so far in regards to supporting VB6 still (at least with the runtime as I know official IDE support has ceased). But there are lots of other areas where newer technologies have pushed out the old ones. I go back to the WinHelp thing. I know it sounds ludicrous or such a small issue, but I have to tell you that it directly affected my .Net feelings/fears because if Microsoft can do it (and did do it) with WinHelp, it can do it with VB6, .Net, or anything else whenever it wants without a care as to the end developer who has to endure the brunt of a "new change in direction" as Microsoft decrees it. (I'm not trying to Microsoft-bash so I hope you don't take it that way).

As you probably know, WinHelp was really old. Windows 3.1 days. HTML Help now is also really old (1997-ish!). A lot of software used WinHelp for their help files because that was the de-facto standard for a long time. And some people (like me) just plain preferred it to HTML Help. While probably 75% of software in recent years moved to HTML Help, I would I think safely estimate that around 25% of Windows software STILL used WinHelp. When designing Vista, Microsoft removed WinHelp support entirely. The stated reason was/is that it was so old (the KB actually specifically gives this as a main reason) and cited security concerns. However, as someone who has been an active developer for years and have kept abreast on security issues, I know for a fact that HTML Help has historically had a LOT more problems than WinHelp. The real reason that Microsoft got rid of WinHelp is because they (the team working on Vista) WANTED to because they thought it was "too old." Nevermind the 25% of developers with software that would need to spend a lot of time (and possibly several hundred dollars for the tools) to convert all their help to HTML Help. See, it just felt like Microsoft made the decision to do something without giving a care about the end-developer that the decision affected. I mean, how hard would it REALLY have been to include WinHelp on Vista...Not much (and certainly not much disk space!) And to add insult to injury, Microsoft did not even provide a tool to make it easy for the developer to do this - they just said - in essence: "There are many tools to help you do this - go buy one."

Even after converting it, I KNOW that it is only a matter of time before HTML Help is declared outdated (after all, it is 10 years old now and quite frankly LOOKS outdated - even more than WinHelp to me!) And the cycle will repeat again. It's just maddening, Beth.

As a consumer and as a developer, I expect that as Microsoft innovates and technologies like .Net move forward, that there also is a healthy respect for the tools and technologies of years past and that Microsoft doesn't so easily dismiss them or the customers who have used them (or still use them). People build whole businesses on these technologies. And Microsoft's "end of support" can cause great trouble and cost outlay and even severely hamper these businesses.

I agree with your points about the development process with a language such as .Net. I see VAST improvement in using .Net in any type of corporate environment with many developers. But, as you know Beth, there are ALSO independent developers that have their own programs. Much of the software available for Windows (especially in the shareware/freeware type arena) is developed by 1 or 2 developers. To be honest, I don't see (and never have seen) nearly the gains to this group of people with .Net's massive shift. I have several large personally written and maintained VB6 programs and to tell you the truth, I have rarely had any problems in maintaining it. Yes, I know it is all on "one layer" as you mentioned, but when you're the only person working with it, "one layer" is just fine! Yes, there are other issues in maintaining a VB6 program as OS technologies move forward, etc. But this also goes for .Net too (such as newer Vista technologies, etc.).

This gets to one of my other points which is that it has always seemed to me that Microsoft has made and promoted .Net as primarily a corporate product. But, as I *think* you probably know, there are lots of non-corporate developers and .Net has had trouble appealing to them. Many of them are using other products such as Delphi, etc. With the removal of VB6 and Visual FoxPro (as you mentioned), it has seemed to me for some time that Microsoft has left the casual/independent/small business developers out in the cold.

I don't believe it has to be this way and that is why I encouraged you (and any other Microsoft employee who will listen) to not forget that there are LOTS of different kinds of developers. I am not in corporate America. I do not manage a massive IT department or even a "worker bee" in such an IT department. I am however a developer with several software products who has also worked for small businesses in this regard. And we ALSO can influence the corporate developers (many of today's successful software products were started/made by entrepreneurial developers outside of Corporate America).

Since I've already typed so much (this is something I'm passionate about as you can see , I might as well share something else:

Initially, one of the biggest downsides to .Net IMO was the size of the Framework/lack of native OS support. This is because when .Net was introduced, the Framework (1.0 at the time) was not installed on many peoples' computers. And adding 22MB to a program to be downloaded over the Internet just didn't make much sense (especially when something like VB6 only has a 1MB runtime that WAS installed on many computers). Now days, there's a lot more of the framework around and this isn't nearly as much of an issue. However, I will tell you that I believe that it has already gotten fairly confusing between 1.0, 1.1, 2.0, and now 3.0 (which is really 2.0 with extras - which in-and-of itself is confusing!). And what apps will work on what, etc. Plus, while a user might have 1.1 framework, they might not have 2.0, etc. Again, this isn't nearly the issue in the corporate world where all updates are managed by an IT department. But it IS an issue when talking about regular folks as the users....when talking about what version of the Framework Uncle Jim has or my neighbor has, etc.

Anyway, these are all just some thoughts for you/the team, whether they are of value to you or not. I do thank you for taking the time to read them and I thank you much for your previous reply! The simple fact that you (and other team members) are even here on this forum to address some "real world developer questions/comments" is a VERY positive sign in my book and is a great, worthwhile step that help alleviate some of the type of fears that I have stated (whether founded or not).

[funkyonex]

Hi Chris,

Like you, I never worked in the "corporate" world, really (not until Microsoft). I always worked for small ISV's or consulting companies with only a few developers on a team so I understand versioning, upgrade and migration pain. I know I keep saying it, but the key is to always make sure your design is layered and has dependencies on other services or components in isolated areas so that it is easy to make changes. I'd argue that business requirements change faster than technology and the right architecture will help in both cases. It's much much harder to migrate an application's business requirements and technology if the design is a single layer. The dependencies are to numerous to be cost effective to do so many times. However, even in the scenario where you have a single-tier application but it's critical to take advantage of some new feature in .NET, you can do so with interop and the Interop Forms Toolkit will help.

The right architecture will help you move to different communication layers, presentation layers, and data access layers. What will come after WPF? WCF? ADO.NET? I don't know, but if we make sure that the dependencies between components are controlled and we use discipline and the right design patterns it shouldn't matter because it's easy to migrate this type of architecture later.

We've been saying the same thing for years whether it's called DNA, loose-coupling, or SOA. It makes sense not only from a technology perspective but also a business perspective. And it's not just for large corporations, small businesses benefit from the right designs as well. This is where I think Visual Studio 2008 really does help. It addresses most of the design challenges we faced using Visual Studio 2005 on .NET 3.0 especially regarding WCF tooling, n-tier datasets, and offline data caching on clients. I personally think the .NET platform will be around for a long long time and you can opt-in or out of the new features. Yes tools will always be behind platform innovations, but just because we *could* use Silverlight doesn't mean I'm necessarily going to because I may need better tools and controls first for the type of application I am building.

And I don't think that Microsoft will just "drop" an entire platform like .NET. For instance, COM is still all over the place and we've had .NET for over 8 years. I guess I haven't had a really bad experience with support for older products from Microsoft. They have always been up front about when support would end for things I developed with/on and that gave me ample planning to refactor the isolated pieces of the application that would be affected. For instance, moving from .NET Framework 1.1 to 2.0 I wanted to take advantage of the new data binding features, this didn't affect my entire architecture, just my UI. I took advantage of it right away in my new forms and the older ones I upgraded one at a time and only if I needed to go into them to modify or fix a bug anyway. The point is the migration forward on the .NET platform has always been easy from a development perspective because of the way the application was designed and because you can choose to opt-in to only the features you want to take advantage of. Generics is another great example. I didn't run all over the system making changes to use generics, I just started using them from that point forward. And if I happen to be in some older code fixing/enhancing it anyways later. then I would convert the code to use them.

Now deployment issues based on versioning can be an issue, I agree it can be a beast. But with Visual Studio 2008 they've alleviated some of this by allowing you to still target the 2.0 framework if you need to, the feature called Multi-targeting. And to be honest I had a much harder time in the past keeping my COM-based application versions straight for each customer (dll-hell), so requiring a one-time install of a framework to get xcopy deployment was still a win in my view. And there are third-party linker tools if you really want to target a certain OS and compile a single exe. I just rather compile-once then deploy anywhere so I like to go with click-once deployment that automatically downloads and installs the framework on the machine first before deploying the application.

So I guess I'm saying that I do understand, I've been there and learned the hard way too. But I do think that .NET is for every type of application be that small business or corporate. The tools are helping us layer our applications, we can opt-in to new features, we can deploy over the web, and now we can target multiple frameworks. It's up to us to figure out "when are we going to buy that new computer"?

HTH,
-B

[RhinoBull]

Sorry everybody but I think that this thread has gone too far from the orignal question - versioning could be a good topic for a brand new thread.
As far as OP is concerned this thread is resolved (or shall I say "difficult to resolve").

Best regards.