Moving large vb6 app to web or winforms. You decide!

Question

I'm working on porting a large vb6 application to .NET. The current app is a desktop app that communicates with a set of local access databases. There are about 200 forms in the application and about 100 tables. The screens are mostly complex. Most show master-detail relationships, lots of rows in embedded spreadsheet and dynamically generated editing controls.

They will port it to .NET. I'm not sure if they will want it web-based or winforms. To me, it seems that the application is better suited for winforms. Thankfully, the access databases will be replaced with sql server regardless of choice.

My reasons for winforms:

• Richer UI.
• Client caching
• Faster development. Winforms is productive for me even though ASP.NET is light years more productive than classic ASP. I would still rather work in winforms.
• Can display more data and spend less time concerned with managing state.

I plan to breakout the business/data layer into a seperate library. The business objects in the library will be able to be used either by the winforms or web app.

I'm thinking that if we port to winforms first and have a clean seperation of UI and business logic, I will be able to reuse the business logic in a web version at a later date. Given the business/data layer is in a seperate library with no UI dependencies.

In the end, it's not my decision to make but I would like to hear your experience moving large windows apps to asp.net.

What was your experience moving a large desktop app to asp.net? How would you approach a project like this? Would you rather port this app to winforms or asp.net? Why?

Thanks! Steve

Answer 1

One major advantage of porting to a new ASP.Net Web app would be that you will have a lot more opportunities to clean it up.

When moving to winforms, there will be a great temptation and pressure to just "port it screen for screen", while if you go to web you will have the opportunity to refactor and improve at a more fundamental level.

My company is currently porting a fairly large legacy VB6/Access app to ASP.Net, and with AJAX (and now Silverlight) it's possible to get a really high level of visual quality and complexity in the UI on the web these days. There are obvious advantages from a user access and deployment standpoint as well.

As far as how to approach the project, I have had success using an iterative approach -- build out a thin slice (implementing a single feature) to prove out the architecture, then add in features based on priority and complexity.

Answer 2

I would suggest that you do your port in stages to make the transition easier. The first stage would be to port from VB6 desktop to .NET desktop (win forms).

Then in the second stage, if still needed, you move all or parts of the .NET desktop to an ASP.NET GUI.

The step from VB6 to .NET is in itself quite large for a team to make, regardless of GUI choice. The staged approach would allow your team to get to grips with .NET in an application style more similar to the current app.

Your goal to separate business logic into re-usable libraries is therefore important for this staged approach to work. If you take this approach, you have much more flexibility about the GUI type (or types) used.

For example you could have all simpler screens provided in an ASP.NET website, with an auxillary WindowsForms app containing more complex screens that users can download as required. Importantly both of these would use the same business logic libraries, they are mostly just different interfaces to the same application.

ASP.NET (or web development in general) requires a quite different developer mindset when dealing with state, cross browser, html/css etc.

I recently worked on a port/migration of a large Delphi desktop app to .NET. The goal was to go to ASP.NET, however this fell over completely because the existing team had limited web development experience and tried to just re-implement the dektop app using ASP.NET. I'd say that this is a much bigger risk when compared to re-creating screens in Windows Forms, at least the end result will be usable and provide end-users some value.

While Ajax and jQuery have made great improvements to the richness of web GUIs, it sounds like your the existing app has some areas such as spreadsheet presentation of data that would be easier to implement efficiently in a desktop app.

In summary, the "ideal" is to move the business logic and rules to .NET in such a way that you can then simply "plug-in" a user interface at a later date. This may be much easier said then done, but that is the goal I normally aim for.

Answer 3

All I can say is that you should NOT start over! In one of the StackOverflow Podcast the subject was should you rewrite an application to get the benefits of a new language, the answer is no! The example Joel Spolsky gave was Borland C++ Builder. They lost to Microsoft VC++ because they started over from scratch. Then Jeff Atwood went on to say that even though WordPress is written in PHP (not a good language in my opinion) the overall idea worked out.

Main Point:
Don't start over because you lose all the experience you gained by building on a solid foundation.

Answer 4

First off, Winforms is dead. Why anyone would start a new desktop program with WinForms is beyond me when WPF has been out for nearly two years. Why move your client from one technology (VB6) that is very, very outdated to another that will be outdated very soon? Please don't take this wrong, but unless you have to support versions of Windows older that XP I think it is actually irresponsible to start a WinForms project in 2009. Here are the downsides vs WPF:

1. XAML, WPF and Silverlight are the focus and Microsoft.
2. WPF is much, much more powerful graphically than Winforms (at least as far as ease of developing a very rich UI).
3. Databinding in WPF is a quantum leap ahead of Winforms; it will save you time.
4. WPF is stable and has seen significant performance increases over the last few SPs and versions.
5. Like all old MS technologies, Winforms will sooner or later die. It is obviously now the old technology.

Now for ASP.Net. This sounds like what you are converting is a fairly straightforward, internal app. ASP.Net is suited for just such a thing. While ASP.Net MVC is almost out of beta, it doesn't yet have the arguments against ASP.Net that WPF does have against WinForms. We do ASP.Net + jQuery at work and it works very well. We are also doing Silverlight, which you might look into. I have really enjoyed working in it. If this is an internal app, you can probably count on the Silverlight plugin being installed on all of you browsers.

Now for general pros of going to WPF vs ASP.Net:

WPF

1. Easier code migration from VB6 desktop to another desktop environment. You might be able to save a lot of your logic, although it will need to be translated to VB.Net or C#. You are going from one stateful environment to another. Not so with ASP.Net.
2. Easier to test (especially if you have to support multiple browsers).
3. Possibly faster to develop (especially if you have to support multiple browsers).

ASP.Net

1. Easier to distribute updates that a desktop app (all you do is update your web server).
2. Can be used on a wide variety of desktops and even mobile devices if authored correctly.
3. Can provide much of the dynamic nature of a desktop app with extra development effort.
4. Can be leveraged for future products that might be public facings.

Good luck on your project!

Answer 5

If you really want to go crazy, and don't mind using the latest technologies, have a look at ASP.NET and Silverlight 3 . Looking at the video's of Mix 09, there are some great examples that deal with this.

In addition the Silverlight app can be run out of the browser, thus being able to provide the desktop experience, but with the pros of being updated whenever you update your code etc. And I personally feel that Windows type applications (so including Silverlight) are nicer for data entry purposes then web based apps (although the use of Ajax does help)