RE: shift appl. VB6 --> .NET
- From: "Cowboy (Gregory A. Beamer) - MVP" <NoSpamMgbworld@xxxxxxxxxxxxxxxxxx>
- Date: Thu, 14 Jul 2005 08:34:02 -0700
I would figure out what it would take to write from scratch in .NET,
realizing that your team understands the business better right now than they
did when they first started in VB6. This is a good worst case estimate, after
you add on the training time to come up to speed in .NET. The benefits:
1. You have probably already noticed problems in design, as the business
rules were not correct from the start (this will happen again in the .NET
world, but you at least clean up the design).
2. The migration tools are marginal at best.
3. Redesign allows you to start your developers on learning the new paradigm
(more below).
4. It is often quicker to build the new app than fix the migrated FUD.
You can then determine which layer of the app would be best served moving to
..NET and start on it. Once the layer is complete, you still have a working
app, albeit one that is part COM and part .NET (not an optimal situation).
This allows you to work one tier at a time and start realizing some .NET
benefits without biting off the entire app.
There are migration tools, but realize they add a lot of COM interop and
training wheels. They are good to get a leg up, but you will likely require
huge amounts of refactoring to really have the application make sense as a
..NET app.
>From my experience, choose C# as your language (or at least a language other
than VB.NET). While syntax is similar in VB and VB.NET, I find the
detrimental effects of having developers continue to attept to write in a VB6
(COM) paradigm outweighs the time to learn a new syntax. With the new syntax,
the developer makes the paradigm shift as part of the language and is less
likely to attempt to write COM style objects in the .NET world.
--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
***************************
Think Outside the Box!
***************************
"jens@xxxxxxxxxxxxx" wrote:
>
> Hello NG,
>
> This question regards a migration of a vb6 application to .NET
>
> Since 2 years we develop and extend an administration/reporting
> application
> based on VB6, Crystal Reports 10 and MS SQL Server 2000 which is
> including as well the control
> of an Excel calculation module via COM.
>
> Now this application should be shifted to .NET, for what we have now to
> calculate the estimated amount of time / money for this.
> Question is, how shall we procede in this to get a result which is as
> closest to the reality as possible and which issues we have to pay
> attention to?
> As annotation I can say that this application is programmed object
> oriented as much as it is possible in VB6.
>
> In a little brainstorming I got up to now the following main points we
> have to think about:
>
> 1. selection of the target language in .NET (c#,java,vb.NET)
> --> which language has which advantages / reason to choose it
> --> or is it only a matter of which language suits the most to the
> programmers?
> --> because at the end it is in any case translated into Intermediate
> Language
>
> 2. can we use migration tools (converter and other tools)?
>
> 3. because .NET uses extended possibilities of object oriented
> programming (z.B. real inheritance., polymorphism ..) we probably have
> to do a refactoring
>
> 4. maybe the program design should be checked in general und maybe
> modelled in a new way,
> because we have the work of reprogramming anyway
>
> 5. is it possible to convert the application (half automatic - see
> point 2) nearly 1:1
> and to use it first like before, and then bit by bit to overwork the
> parts (according to .NET's possibilities) which then are going to be
> changed or to get new features in any case, (bit by bit refactoring)
>
> 6. is control of Excel via COM possible like up to now?
>
> 7. how is it going with the implementation of modules in other
> languages
> (e.g. time critical calculation routines programmed in C)
> --> or is the only possibility for this, to program directly in the
> Intermediate Language and compile it to native code?
>
>
> Has anyone been doing this already and has faced problems, which
> haven't been expected before?
>
> This topic was initiated by the costumer, but the question remains, if
> it's really necessary.
>
>
> For me as a programmer/program designer I see as advantages mainly the
> extended possibilities of object oriented programming, safe support of
> the base technologies in future and a bigger and more flexible variety
> of functions and features which his been up to now only available by
> using 3rd party components or tricks with Windows API functions, as
> well as I expect better support in creating installation packages and
> automated documentation, which again is in VB6 only possible with
> 3rd party components in a proper way.
>
> The general question is how long the DLL concept so far as well as the
> COM technology and the used API function will still be supported,
> meaning starting when we have to go to another technology
> in any case.
>
> Thanks for your help!
> Jens Consr
>
>
.
- References:
- shift appl. VB6 --> .NET
- From: jens
- shift appl. VB6 --> .NET
- Prev by Date: Are Classes with Static State Ever Garbage Collected ??
- Next by Date: RE: Inline code in .Net
- Previous by thread: shift appl. VB6 --> .NET
- Next by thread: AIC component
- Index(es):
Relevant Pages
|
Loading
