Opinions, please -- vb.net upgrade

Andy Shaw
7/17/2003 5:12:14 PM

We're finally starting to look at moving our application suite from VB6 to
..Net. I have my own opinions on the scale of the process, but I'd be
interested to hear what people here think as well.

To give you some background, we have one EXE, a container, that initialises
services and dynamically loads controls. Which controls are loaded is
determined by the user at run-time, as we have a "design-mode" that allows
users to split the screen up any way they like and throw whatever (of our)
components they like into whichever section. Each user may define any number
of such screens and switch between them at runtime, dynamically unloading
and loading controls.

This is all very straightforward under V6/Com, we simply store the progids
and license keys of our components in the database and each user's profile
in an XML document. It being so easy, the application suite is quite large
(124 OCXs 186 DLLs).

The issues I have seen so far are:
1. No COM = No ProgID or license key. We can resolve this with the
Reflection classes using the FQN of each control (which we'll stick in the
db) but has anyone had interesting issues with dynamic-load of assemblies?

2. Assuming there's not been a revolution between 2002 and 2003 that I've
not read about anywhere, it's still not possible to host a Windows Forms
control on a VB6 form without manually implementing all the nasty, evil
little COM interfaces yourself. This, then dictates the order in which
individual components may be converted - we can cherry-pick a few of the
simpler DLLs to start with, but we have to do the container (the single
largest component) before any of the OCXs.

3. There being 311 vb projects to convert, the conversion process will take
a long time. Given that we can't afford to halt new functionality
development during that time, we're gonig to be looking at a year or so of
Interop. Has anyone used Interop on this sort of scale (both number of
components and time) and if so, are we going to regret it?

4. If we simply convert (and I'm not suggesting, having lurked here for more
than 20 seconds, that we'll be using the upgrade tools) each of the
components, we'll be carrying all the VB6 ("object-based") design into the
..Net ("object-oriented") environment, which is surely going to be foolish.
Of those that have started large upgrade projects, does anyone disagree that
a total review of our design and internal architecture is vital and will
save us a large quantity of time (and pain) in the medium-to-long, if not
immediate, term?

Fairly involved for a first posting, I know, but none of the reference
material I've found talks about conversion or interop projects on this
scale.

If you want to email me, note that "catchmeifyoucan" is not part of my email
address...

Regards and TIA

Andy Shaw

Tim Sneath [MS]
8/6/2003 12:27:09 PM

Andy,

This is a big topic, as you rightly recognise. This kind of application is
not straightforward to migrate because of the often complex interactions
between container and controls. I'm not able to give a comprehensive answer
here, but a couple of pointers at least:

1) Have you looked at the LicenseProvider class and attributes in
System.ComponentModel? These are compatible with ActiveX controls and
support the .NET Framework. Further details here:
http://msdn.com/library/en-us/cpguide/html/cpconlicensingcomponentscontrols.asp

2) Upgrading the container first is a wise idea, because it means you can
then start work on shiny new (TM) .NET components that don't need to cater
for the old world. You're right that we only provide limited support for
ActiveX controls created with Windows Forms for a variety of reasons -
mostly due to diverging quality of support provided by COM containers,
combined with a poor-quality experience. Even if you did build a component
that only supported COM data types and acted like an ActiveX control, you'd
be spending most of your time in the .NET world designing things the old COM
way, which really wouldn't help very far in moving to the shiny new (TM)
world.

3) I've come across a couple of companies who've tried to do this; one took
the opportunity to review the application architecture and do a larger-scale
upgrade, the other stuck with it. To be honest, I've not seen the
post-mortem from either company to establish which approach worked best.

4) I think it's likely that you'll get some useful output out of a
reexamination of the architecture in the light of .NET, but actually your
experiences and learnings in migrating will greatly assist in understanding
where new .NET capabilities are most valuable. So it's a bit of a
chicken-and-egg situation. If I were you, I'd start with a proof-of-concept
over a period of 2-4 weeks to pull out the biggest issues that you'll face,
and then go back to the whiteboard and look at the core pieces of your
application in the light of your learnings.

Hope this helps a little, and good luck!

Tim Sneath
Microsoft UK

--
This posting is provided "AS IS" with no warranties, and confers no rights.
Also, I'm just one engineer, rather than the accumulated wisdom of the
entire Microsoft Corporation :-)

[quoted text, click to view]

vb.net upgrade : Opinions, please