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.
--
"Joseph Geretz" <jg*****@nospam .com> wrote in message
news:%2******** ********@TK2MSF TNGP11.phx.gbl. ..
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 -