all groups > vb.net upgrade > september 2005 >
You're in the

vb.net upgrade

group:

port or bag it and start over


port or bag it and start over jon f kaminsky
9/2/2005 5:26:09 PM
vb.net upgrade:
Hi- (x-posted in dotnet.framework.adonet)
i have been struggling with porting a large VB6 project over 55 forms, 5
data environment objects, each with 50-100 commands (over 30 total), plus all
the hand-coded connections, commands and recordsets where applicable.
And with the Crystal Reports XI RDC, now a total bitch to deal with. Running
the code mangler (converter) just timed out until I removed all references to
Crystal Reports. I am still faced with an ungodly amount of flagged ADO
code, along with many instances of missing objects where there was now
applicable replacements Hierarchial flex-grid, datagrid, datalist, datacombo).

So I guess this point I am asking myself, should I try to get this thing
running, not to mention having to use the compatibility libraries and code
band-aids to run with the ADO stuff? I have over 1500 issues to fix
(including 590 outright errors) before I can even build this thing. Perhaps I
should do a re-write.

I think the bulk of the work is going to be converting all that data
environment stuff into .NET code. Then hand-writing all the code to bind it
to what's left of the existing controls.

I did see that there is a dataform wizard, but when I looked into it, it
appears to only generate oledb provider object code instead of code for the
SQL Server provider that I keep reading I NEED to be using. Even changing
that generated code over to the SQL provider is a major PIA. AND, I cannot
believe all of the freakin' code that wizard puked out for one lousy select
statement on 10 columns of data. I will be hand-coding until next summer if
this is required of each ported command.

Anyone with similar experience? Was is worth it? Is there a tried-and-true
process to go from a boat-load of data environment objects bound to Activex
controls, either directly, or through hand-written code? Any advice, help,
flame appreciated.
--
thx,
jf kaminsky

--
thx,
Re: port or bag it and start over Earl
9/15/2005 3:55:33 PM
As you've probably read by now on other sites, "upgrade" is quite the
misnomer for VB.Net. My experience has been that trying to upgrade an app of
that size is more trouble than it is worth. Either support what you have or
rewrite it. Particularly with 3rd party components and a lot of grids,
you'll have no choice but to go in and rip out 70% of the code in order to
"upgrade". Note however that you *could* still use your existing ADO classic
code in VB.Net, although that really doesn't fit into the .Net paradigm.

A final point. Understanding VB.Net *before* you try to do an upgrade makes
the process much less painful. It's a lot harder to know what really needs
"fixed" if you do not grasp the fundamental tenets of the .Net framework.

[quoted text, click to view]

Re: port or bag it and start over Ole Nielsby
9/27/2005 12:00:00 AM

[quoted text, click to view]

I'm working on a project that might interest you, though it is
still in the early stages of development and perhaps I am a
bit early with this. Anyway, if your alternative really is
handcoding until next summer, you might want to consider
having a talk with us.

"Us" is the VB6 revitalizing team at Danish Technological
Institute, and basically, we are refactoring other peoples'
ill-structured VB6 projects into well-structured or at least
manageable VB6 projects.

The project I'm referring to is called DotSpaghettiNet and
aims at providing an adaptable VB6 to xxx.NET converter
with some built-in refactoring capabilities, including SQL
stuff.

As said, the DotSpaghettiNet project still has some way
to go - maybe next spring is a realistic bet for full-scale
conversions. It has yet to be decided whether the target
will be VB.NET or C#, or perhaps both.

However, we might be able to help you more swiftly with
smaller refactoring tools tailored to your specific needs
(i.e. tools for massaging your code before it goes through
the MS mangler, or automating some of the more tedious
fixing work on the converted code).

If you are interested in further discussion about this, mail
me at ole.nielsby@snailmail.dk but without the slow slimy
animal (spam prevention - I'm using my private mail address
for usenet-related conversations).

The (english) website of our company is
http://www.danishtechnology.dk/
in case you wonder who and what we are.

AddThis Social Bookmark Button