[mono-vb] VB6 and the future cont
Robert S Conley
robertsconley at gmail.com
Wed Aug 23 23:17:52 EDT 2006
Rafael Teixeira wrote:
> VB6 syntax is somewhat easy to compile into a .NET assembly, the
> really trick part is that VB is too tied with COM, so it isn't always
> possible to guarantee things will work.
I agree that Visual BASIC forms and controls could prove impossible to
compile. But my application also has a dozen ActiveX DLLs that are just
code with little reliance on COM other than then the fact they are in
ActiveX DLLs. I manually transferred a few of the simpler projects to
.NET and they work much as they do in the ActiveX version,
> I've written lots of code in VB6 and know how hard it is to make it
> work without third-party controls and some custom C++/ATL components,
> and both would pose real problems to compile and to run outside
> Windows and even on .NET.
I am not trying to be argumentative, but the problem I run into this. In
the Visual Basic 6 world you got a lot of people who use VB6 with a
database front end with crystal report as their report engine. Then you
have a group that is probably just as large that used VB6 for a variety
of apps that are made of mostly forms interacting with each other. Then
have vertical market guys like me which are a small minority. In general
we avoid dependence on 3rd party control like the plague, and have a
huge amount of code wrapped up in ActiveX Dlls. While the last two
groups are hurt, the third group has the best chance of benefiting from
a VB6 .NET complier.
Because the vertical market guys are such a small part of the VB6 market
we can't get Microsoft to hear us. C/C++ on the other hand has a higher
portion of people making standalong apps so they get the hybrid
compliers that allow to keep their old code going and mixing in .NET
stuff when they want too. I don't if that true but it the only thing
that make sense given the behavior of the managers I communicated with.
> Mono doesn't support COM, yet, and will support it only in Windows,
> but that may not stop you as maybe what you really want is just to
> compile then with a vbnc-derivative and run them in plain MS
So we are all on the same page. Our lowest level DLL is called
ViconUtility. everything in our problem depends on it but it depends on
nothing else. I want to be able to compile that and get a .NET assembly.
Test it using the same tests we use for VB6 and verify it is ok. Note
this not through COM Interop but our tests compiled with the
vbnc-derivative. With that work we go on to the next DLL. ViconObjects
which has our data structures. We compile that but the reference to
ViconUtility will no longer be through COM but through the .NET way of
references. From my manual tests this will work. Then I can run my
ViconObject tests. Then I add the Shapes Library, the File Import/Export
Library, the Report Library and so on.
Finally I have a version of our software running that has everything but
the forms. Now the way our software works is that Form do nothing other
than pass and receive messages through an Interface. We did this a
couple of years ago so that we can have automated UI testing. By the
time I reach this point I am ready to pick a form package (Winform, Gtk,
or whatever) and start building forms and having them implement the UI
But without that VB6 to .NET compilier it takes me too long to reliably
convert even the Utility DLL
> Even so I believe that the old components will tie things down: for
> instance, the current COM-Interop infrastructure may not be
> appropriate for the task, as you already pointed some limitations it
> imposes. Also dealing with .frm files, are surely to bring some hard
> to deal problems, as they don't map very well to SWF (and even less
> with WPF/Avalon).
I hear you, but I can implement nearly all of the Gang Of Four Design
Patterns in VB6. So for people who are not as well factored as our
company's application they can re-factor their original app in VB6 using
automated testing to the point where a vbnc VB6 complier can get
everything but the forms. It will take longer but each step can be
tested to be correct, including the vb6 to .net step. But without that
VB6 complier we can't do it. The translator wizard chokes on every piece
of non-trivial code.
I done three conversion in the 20 years, in every conversion. there was
a phase where I was re-working original code, and testing. Because the
change was easier to port while performing the same function. With a
vbnc based VB6 complier then I can do this process a lot more reliably.
> For me, all the thousands of lines of VB6 code I wrote have been in
> the care of other hands for the last 5 years, and since I've started
> all new projects natively in Mono/.NET using C# and some in Java, so I
> really doesn't feel the pressing need for a VB6 compiler, but I
> sympathize with you, as my first attempt to migrate those hundreds of
> VB6 classes and/or forms to VB.NET with the VS.NET wizard,
> 5-and-a-half years ago, generated something I could only call garbage.
Some of us don't have the option of handing it off to other people and
starting again. We can't replace this software. At some point we have to
update to the current platform. I am trying to minimize the cost of
doing so, put putting us in a situation where we are not solely
dependent on Microsoft again.
More information about the Mono-vb