[mono-vb] VB6 and the future cont

[Robert S Conley]

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
> .NET/Windows.
>
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 
interfaces.

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.

Thanks
Rob Conley