Discussion:
How to deploy: VBA macros or Office Add-in?
(too old to reply)
Łukasz Magdziarz
2009-12-04 09:14:54 UTC
Permalink
Hello,

I have developed an application using MS Project VBA macros.
It works good and fast.

The problem is, that I have some doubts about ways of deployment of my tool.

The VBA macros are fast, but there is a problem with installation and
protection of a source code.
On the other hand, VSTO Add-ins for Office offer a code protection and nice
installator, but they work terribly slow.

Can you please advise me how to deploy my tool in the best way ?

Thank you!
Lukasz Magdziarz
Jonathan West
2009-12-04 15:05:45 UTC
Permalink
You're talking of MS Project. this is a group dealing with VBA in MS Word.

if you really meant Word, then take a look here

Distributing macros to other users
http://word.mvps.org/FAQs/MacrosVBA/DistributeMacros.htm

If you really meant Project, then you need to ask the question in a Project
group, perhaps microsoft.public.project.vba, where there will be Project VBA
experts able to help you.
--
Regards
Jonathan West
Post by Łukasz Magdziarz
Hello,
I have developed an application using MS Project VBA macros.
It works good and fast.
The problem is, that I have some doubts about ways of deployment of my tool.
The VBA macros are fast, but there is a problem with installation and
protection of a source code.
On the other hand, VSTO Add-ins for Office offer a code protection and
nice installator, but they work terribly slow.
Can you please advise me how to deploy my tool in the best way ?
Thank you!
Lukasz Magdziarz
Łukasz Magdziarz
2009-12-04 16:29:21 UTC
Permalink
Thank you very much for your answer.
I meant Ms Project, I decided to post my question also here, becouse the
problem I have is actually related to all Ms Office applications.
The link is very helpful - it gives me some ideas how I could deploy my
tool.

But is it really so, that it is still better to use macros instead of COM
addins, written in VSTO?

Kind regards,
Lukasz Magdziarz
Post by Jonathan West
You're talking of MS Project. this is a group dealing with VBA in MS Word.
if you really meant Word, then take a look here
Distributing macros to other users
http://word.mvps.org/FAQs/MacrosVBA/DistributeMacros.htm
If you really meant Project, then you need to ask the question in a
Project group, perhaps microsoft.public.project.vba, where there will be
Project VBA experts able to help you.
--
Regards
Jonathan West
Post by Łukasz Magdziarz
Hello,
I have developed an application using MS Project VBA macros.
It works good and fast.
The problem is, that I have some doubts about ways of deployment of my tool.
The VBA macros are fast, but there is a problem with installation and
protection of a source code.
On the other hand, VSTO Add-ins for Office offer a code protection and
nice installator, but they work terribly slow.
Can you please advise me how to deploy my tool in the best way ?
Thank you!
Lukasz Magdziarz
Jonathan West
2009-12-05 01:57:43 UTC
Permalink
Post by Łukasz Magdziarz
Thank you very much for your answer.
I meant Ms Project, I decided to post my question also here, becouse the
problem I have is actually related to all Ms Office applications.
The link is very helpful - it gives me some ideas how I could deploy my
tool.
But is it really so, that it is still better to use macros instead of COM
addins, written in VSTO?
I've been sriting code and add-ins for Word for 15 years. I have yet to find
a convincng reason to move to VSTO.

My code spends almost all its time manipulating the Word object model. For
that, i've found that VBA is substantially faster than VSTO, because VSTO
has 2 levels of interop to go through for every commend. There is the
Net-COM interop layer, and then the fact that the command is issued
out-of-process. Word VBA runs in process.

However, if your program is primarily a .Net program, and only does a bit of
office interop (e.g. to generate a report) then it may make more sense to
avoid VBA.
--
Regards
Jonathan West
Łukasz Magdziarz
2009-12-18 17:37:48 UTC
Permalink
But it there a kind of transaction?
Like start transaction and end transaction - to avoid calling each COM call
in a new process?
There has to be something.

Please, maybe someone has heard something?

LM
Post by Jonathan West
Post by Łukasz Magdziarz
Thank you very much for your answer.
I meant Ms Project, I decided to post my question also here, becouse the
problem I have is actually related to all Ms Office applications.
The link is very helpful - it gives me some ideas how I could deploy my
tool.
But is it really so, that it is still better to use macros instead of COM
addins, written in VSTO?
I've been sriting code and add-ins for Word for 15 years. I have yet to
find a convincng reason to move to VSTO.
My code spends almost all its time manipulating the Word object model. For
that, i've found that VBA is substantially faster than VSTO, because VSTO
has 2 levels of interop to go through for every commend. There is the
Net-COM interop layer, and then the fact that the command is issued
out-of-process. Word VBA runs in process.
However, if your program is primarily a .Net program, and only does a bit
of office interop (e.g. to generate a report) then it may make more sense
to avoid VBA.
--
Regards
Jonathan West
Jonathan West
2009-12-19 19:49:23 UTC
Permalink
Post by Łukasz Magdziarz
But it there a kind of transaction?
Like start transaction and end transaction - to avoid calling each COM
call in a new process?
There has to be something.
Please, maybe someone has heard something?
A connection gets made, but each command has to pass through the connection
and be translated from .NET to COM and from out of process to in-process.

No way round that, unless and until Microsoft makes the Office apps run as a
native .NET server rather than as a COM server.

I suspect that the amount of rewriting involved in doing that would keep the
Office developers busy for 5 years, without adding any new features. In
other words, it's not going to happen. Rewriting your code to address
enforced changes of platform is something thwt Microsoft requires of others
but never attempts itself.
--
Regards
Jonathan West
Loading...