Question re Migration of VB6 App to .NET

[Joseph Geretz]

Our company develops and markets a client/server application which is
written in VB6 as a rich Win32 Client/Server application. For a variety of
technological reasons we are looking to migrate toward the .NET environment.
However, a number of business factors make it impractical to accomplish this
through an abrupt termination of the VB6 product and complete rewrite.
Instead, we are looking to perform new development in .NET and slowly over
time migrate existing code to .NET.

At this time, we are looking to add a brand new module to our product.
Obviously, the new module has some connection to the rest of the application
in general. Be that as it may, it is sufficiently encapsulated unto itself
that we are contemplating developing this new module in .NET. I'm interested
in any advice which you can offer about how we might 'plug in' a module
written in .NET into our VB6 application, specifically at the UI layer. We
must provide the user with a seamless UI interface to our application,
regardless of whether the user is interacting with a VB6 Form or with a .NET
WinForm.

Thanks very much for any advice which you can provide.

- Joe Geretz -

 

[chanmmn]

You should be looking at Interoperability:

http://msdn.microsoft.com/vbasic/using/understanding/interop/default.aspx

chanmm

 

[Nick Malik [Microsoft]]

when it is time to add a new module, this may not be the best time to move
to .net

I guess it depends on how independent the new module is.

I've had the opportunity to advise folks on how to move VB6 to .Net in the
past. I usually advise the following:
Step 1: Spend a few days getting used to your code again. Like an old
friend that you've lost touch with, code tends to deviate from the design
during development and maintenance. Take a fresh look. Consider this
question:
If I was to write an altogether new interface, could I use the same objects
I currently have? Would I?

Step 2: refactor the existing code, in the existing language. Clean up any
of the partitioning problems you saw in step 1. Some things will still
creep up in the development later, but taking a little time now to clean up
the objects can really make a difference in your ability to deliver on a
predictable basis.

Step 3: Create an ENTIRELY NEW USER INTERFACE. This is not for the faint of
heart. However, VB6 has a few advantages that your ordinary application
doesn't have. For one thing, all of it's objects comply with the COM
interface. Therefore, you can create an entirely new interface in .NET
without actually removing the old one. You can pop back and forth, validate
functionality, and even refactor the old code while writing the new
interface. Here is where the work done in Step 2 really pays off. If your
business object layer was actually designed to be independent of the U/I
layer, you will appreciate it today. If not, you will need to make it
independent. There is no way around it.

Step 4: retire the old user interface and release the code to business users
or beta testers. It takes time to create the new interface. Someone always
adds an "innovation" or two. Start collecting feedback now. Depending on
your business, it is perfectly acceptable to actually release the code at
this stage. If there are new features to add, do it using the OLD code base
and the OLD language, called from the new interface. In other words, keep
the layers intact.

Step 5: Create a parallel data access layer. This will be used by the .NET
business objects that you write. You will continue to use the VB6 Data
access layer while you still have VB6 components in play. You will use the
..NET data layer for .NET objects. Don't plan on mixing these two... it
isn't worth it. (take that from experience and pain... trying to use the
VB6 data layer from .Net, or vice versa, is a doorway to undue delay and
gnashing of teeth.)

Step 6: Pick a relatively self-contained set of business objects. Something
achievable. Don't go to the biggest, but don't pick the smallest either.
Give yourself a chance to succeed and still learn. Recode those business
objects to .Net. Have your GUI call them instead of calling the VB6
objects. Have the .Net objects call the parallel data access layer. Learn
from the experience.

Step 7: refactor everything. Literally, take an entire dev-test cycle to
just fix the stuff you need to fix. This could be a month or several
months, depending on the size and complexity of your app. Be specific.
Plan your refactoring. Do this only to improve structure. Apply lessons
learned to the new code, as well as fixes to the interface into the old
code.

Step 8: Release.

Step 9: Recode another set of business objects.

Step 10: Repeat steps 8 and 9 until all business objects are recoded in
..NET.

Step 11: buy champagne. Give everyone a week of skiing or windsurfing.

Hope this helps.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--

 

[Cor Ligthert]

Joseph,

In first sight I thought I was disagreeing with Nick however reading it
repeatedly, I think he almost wrote the same as me. Therefore, I changed my
text bellow and deleting parts from the text because that doesn't add
anything.

My experience is that trying to keep older software in newer goes deeper and
deeper and at a certain moment the program parts to make everything
compatible is much larger than the part that should do the business.
(Although it is sometimes impossible not to do that).

I would look first how far my new module is dependent from my existing
application. The database part from VB6 and VBNet is the same, although you
should in my opinion directly use to access it ADONET in while you were
probably using ADODB.

This can become directly a problem when you look at the way you use now your
concurrency (optimistic versus pessimistic concurrency), however directly a
point where you have to make your decisions for the future because it has
has a major influence on using your data on disconnected devices.

My opinion is that when you are able to make a complete new module, which
only have some interfaces on the start menu level of your UI, that than the
growing and renewing part will be better of.

However, what I read between the lines in Nick's message; do those well and
with that, I follow completely the route he describes.

However just my thought.

Cor

 

[Nick Malik [Microsoft]]

Joseph,

In first sight I thought I was disagreeing with Nick however reading it
repeatedly, I think he almost wrote the same as me.

High praise indeed, Cor. Thank you.

I blogged that message. I would appreciate your feedback on how I can make
it more clear. I've answered it before, and I'm hoping that this could be
the foundation for a quick article.

--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik

Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--