VBA & VB.NET, conversion and future

[maronnamia]

Hi,

I have many VBA Applications that open forms and do businness logic
work on the client. This application interoperate with a ActiveX
COM/EXE and others DCOM on a MTS Server that do the business logic
Server side.

Now, while i develop this VBA application on Office XP (and this is a
fix point because this platform is installed on many PC), i try to
migrate tha VBA Applications Architecture in VSO.NET VB or C#, this
for the future

I have some questions for you (some is trivial, but i am a newbie on
..NET platform):

1) VSO.NET is supported only by Office 2003?

2) If i would migrate a VBA Application in VB.NET(C#). What is good to
remain on VBA and what is good to shift on the new platform? This is a
philosophically questions, but now i must evaluate the evolutions of
these VBA applications and the new architecture

3) Is there any book on VSO.NET?

4) What is the best reference for begin in this new world?

thanks to all

Mixre

P.S. Sorry for the cross post

 

[Jonathan West]

Hi,

I have many VBA Applications that open forms and do businness logic
work on the client. This application interoperate with a ActiveX
COM/EXE and others DCOM on a MTS Server that do the business logic
Server side.

Now, while i develop this VBA application on Office XP (and this is a
fix point because this platform is installed on many PC), i try to
migrate tha VBA Applications Architecture in VSO.NET VB or C#, this
for the future

I have some questions for you (some is trivial, but i am a newbie on
.NET platform):

1) VSO.NET is supported only by Office 2003?
Correct.


2) If i would migrate a VBA Application in VB.NET(C#). What is good to
remain on VBA and what is good to shift on the new platform? This is a
philosophically questions, but now i must evaluate the evolutions of
these VBA applications and the new architecture

It is difficult to make any major recommendations, but here are a few
thoughts

- I doubt that the evolution story for VSO.NET is ended yet. If your code is
working ok at present, I would be inclined to wait until at least the next
release of Office to see what they bring out. I would not be surprised if an
embedded form of VB.NET is included, that has the same kind of relationship
to the full VB.NET that VBA has to VB6

- Be aware that moving to VB.NET effectively means more-or-less a complete
rewrite of your application, as even the extremely imperfect tools for
converting VB6 applications to VB.NET do not apply to VBA. You will probably
only be able to justify such work if you really badly need features
available in VB.NET and which cannot be achieved in any other way.

- With VBA, you can pretty much guarantee that it will be available on any
PC that is running Office XP. If you use VB.NET, you will need to install
the .NET framework on all the target machines, which is a multimegabyte
install.

 

[Cindy M -WordMVP-]

Hi Maronnamia,

I agree with Jonathan's assessment. Plus some additional thoughts:

1. At this point, you have no idea how Office versions are going to
change. Things might be added, or no longer work the same in a later
version. As Jonathan says, migrating at this point can really only be
justified if there is something specific in .NET to offset the costs.

2. And as part of the costs you have to include the SPEED. Automating an
Office application from outside that application's VBA projects is
appreciably slower. Doing it from within the .NET framework is slower
yet, because the command have to go through TWO interfaces. Not only
that, but they also have to be "translated" (marshalled) from .NET-speak
to COM-speak. So, for every command that goes back and forth between
your .NEt app and the Office app, you're taking a massive hit.

3. You have to be extremely careful with releasing objects and garbage
collection. Read up thoroughly on handling COM from .NET or you'll run
into all kinds of problems. If you can use VSTO, some of that is
alleviated because a lot of the management is built in; but VSTO only
works with Office 2003.

4. If you do decide to automate from .NET, you'll find it goes much
easier using VB.NET than C#. If you don't need anything specific that C#
offers, then use VB.NET. VB.NET parallels COM programming practices more
closely. For example, you can send named parameters; in C# you have to
list each and every parameter, and send an object ("ismissing") for
those you don't specify.

Now, while i develop this VBA application on Office XP (and this is a
fix point because this platform is installed on many PC), i try to
migrate tha VBA Applications Architecture in VSO.NET VB or C#, this
for the future

I have some questions for you (some is trivial, but i am a newbie on
..NET platform):

1) VSO.NET is supported only by Office 2003?

2) If i would migrate a VBA Application in VB.NET(C#). What is good to
remain on VBA and what is good to shift on the new platform? This is a
philosophically questions, but now i must evaluate the evolutions of
these VBA applications and the new architecture

3) Is there any book on VSO.NET?

4) What is the best reference for begin in this new world?

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 8 2004)
http://www.word.mvps.org

This reply is posted in the Newsgroup; please post any follow question
or reply in the newsgroup and not by e-mail