VBA vs. Managed Code in Project 2007

[thomas.a.ryan]

With VSTO and Project 2007, is there a need or ability to use VBA
scripting in Project 2007? Or is Managed Code (like C#) the only
programming you do in Project 2007?

 

[Jan De Messemaeker]

Hi Thomas,

You nearly gave me a heart attack.. I have cistomers running VBA
applications of thousands of LOC... they would NEVER go to a version that
hadn't VBA! Fortunately, VBA is available just like before!

 

[thomas.a.ryan]

So both are available, which makes sense....

Do you have experience with VBA vs. Managed Code? How much overlap of
capabilities are there? Is there more or less you can do with VBA vs.
Managed Code? Is VBA there to just support legacy? I am assuming that
if you are not supporting legacy code, you would choose the Managed
Code path. Is that a good assumption (or is there limitations to
Managed Code that require you to use VBA - assumption is that you are
only supporting 2007 clients)?

Thanks for your insight,
Tommy.

 

[Jan De Messemaeker]

Hi Tommy,

I know much about Project but I have no clue what Managed Code is, sorry.
HTH

 

[thomas.a.ryan]

Managed code definition - http://en.wikipedia.org/wiki/Managed_code.
Basically it is .NET programming languages (like C# and VB.NET).
Managed code is programming environment is usually done with Visual
Studio .NET (VS.NET). VS.NET supports developing Office Addins with
VSTO (Visual Studio Tools for Office) and the languages you use in VSTO
or languages that produce managed code (code that runs in the .NET
virtual machine - Common Language Runtime (CLR)).

Is that enough acrnonyms for you :>. Hope that helps (probably
overkill, but thought it would help to let you know where I am coming
from). What I am trying to determine is if I were to use C# (a managed
code programming language that is compiled) would I have any
limitations and would I need to have to use VBA (a scripting language).

 

[Jan De Messemaeker]

Hi,

I knowx neither of the products and methods you name - all I know of IT is
Project and VBA (or about)
From other posts I know you can use C++ calling Project's objects (isn't
that called the API?) which are the same as those used in VBA.
HTH

 

[Rod Gill]

Managed code is certainly the way to go for add-ins and large rollouts as
the code should be more secure and easier to implement. However there will
always be a place for VBA. Managed code still runs out of process I think!
VBA code runs in process so it is surprisingly fast.

I would always use VB to talk to any Office application rather than C# as VB
code is quicker to develop with Office Apps. Much better intellisense and
optional parameters make for more readable code. For example to do a sort in
C# you need to provide about 20 parameters, most of them nulls. In VB you
name the parameters you want and only supply them. The result code written
much quicker and is more readable and easier to maintain. It runs at exactly
the same speed as C# so the only advantage of C# is possibly your
familiarity with it. If you know vb then vb will always be better for
working with Office apps.

With VB you can also copy paste VBA apps and have minimal editing to make
the code work.

 

[thomas.a.ryan]

Rod, thanks for that insight. I can see why VB.NET would be a natural
choice (especially with quickly converting VBA code samples - since it
appears there is minimal sample code for Project in the SDK).