*.DOT Add-Ins vs. COM Add-Ins

[Oleg Krupnov]

I'm developing an add-in (in VB) for Word and hesitating whether I
should pack it into a DOT add-in or a COM add-in.

The add-in should have its own toolbar and/or menu, so, as previously
discussed in this group, the best practice for this is not to create
the toolbar dynamically, but to load it from pre-designed DOT addin.

So, there's already going to be a DOT template in the delivery, but yet
without containing any macros - only the menu and the toolbar.

So far, I've been developing my add-in as a COM add-in but now I come
to think that since I already deliver a DOT add-in, maybe I should put
all my code into it as well and go with only one file?

Can anybody provide any experience of DOT add-ins vs COM add-ins?

The potential caveats may be in the following areas:

1) The DOT file isn't compiled to binary, unlike its DLL counterpart.
I.e. it contains the source code somewhere inside. If I want to hide
it, well, I can lock it on the password, but I wonder if it's safe
enough :) Also, intuitively, software just has to be binary :) I can't
help thinking that DOT is rather a document, not a program :) I wonder
if anybody cares though...

2) Security warnings to the user. It looks like they are the same when
installing both DOT and COM addins, but I ask just in case if I missed
something. For some reason, installing a DOT with macros feels to me
somewhat "dirtier" than installing a COM add-in :)

3) Distribution & installation. Obviously, delivering a DOT is far much
easier. No particular installation is needed, no registry settings etc.
It's good at one hand, but on the other hand, I wonder if it's going to
cause any issues, like the copyright protection of my software etc.?

[Cindy M -WordMVP-]

Hi Oleg,

Your analysis is pretty much right on target, see below for my thoughts

Post by Oleg Krupnov
I'm developing an add-in (in VB) for Word and hesitating whether I
should pack it into a DOT add-in or a COM add-in.
The add-in should have its own toolbar and/or menu, so, as previously
discussed in this group, the best practice for this is not to create
the toolbar dynamically, but to load it from pre-designed DOT addin.
So, there's already going to be a DOT template in the delivery, but yet
without containing any macros - only the menu and the toolbar.
So far, I've been developing my add-in as a COM add-in but now I come
to think that since I already deliver a DOT add-in, maybe I should put
all my code into it as well and go with only one file?
Can anybody provide any experience of DOT add-ins vs COM add-ins?
1) The DOT file isn't compiled to binary, unlike its DLL counterpart.
I.e. it contains the source code somewhere inside. If I want to hide
it, well, I can lock it on the password, but I wonder if it's safe
enough :) Also, intuitively, software just has to be binary :) I can't
help thinking that DOT is rather a document, not a program :) I wonder
if anybody cares though...

The binary file is more secure, no question.

Post by Oleg Krupnov
2) Security warnings to the user. It looks like they are the same when
installing both DOT and COM addins, but I ask just in case if I missed
something. For some reason, installing a DOT with macros feels to me
somewhat "dirtier" than installing a COM add-in :)

The user shouldn't be getting security warnings with a COM addin? The
*.dot Addin won't give security warnings if it's installed in the Startup
folder. Also, you'd have the option of digitally signing the project so
that the user could trust you as a "publisher". Then the *.dot could be
stored anywhere and not trigger macro security.

Post by Oleg Krupnov
3) Distribution & installation. Obviously, delivering a DOT is far much
easier. No particular installation is needed, no registry settings etc.
It's good at one hand, but on the other hand, I wonder if it's going to
cause any issues, like the copyright protection of my software etc.?

If the user needs to troubleshoot any problems your Addin might cause, a
*.dot is easier to track down. that's the only point I have to add to
(3). Machine-installed (as opposed to user-profile installed) COM Addins
are the most difficult to find if they're causing conflicts.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
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 :-)

[Ignoramus]

Thanks, Cindy.

It's not the first time when I need to overcome my perfectionism and
choose what is easier to implement, not what "feels better" for some
rather irrational reasons that the users just don't care about :) So
perhaps I'll go with a DOT.

BTW another consideration I forgot to mention is that COM add-in can be
connected to many Office applications, while DOT is Word specific. It's
not my case though, I'm ok with Word only. At last, it doesn't seem to
be very tedious to switch between DOT and COM just in case if such a
need ever occurs, which I doubt.

Yes, you're right. Word doesn't show any security warnings for a COM
addin when starting the addin manually, but it does for a DOT addin. If
the "Trust all installed add-ins and templates" is unchecked, then Word
generates equal security warnings for both COM and DOT addins. BTW when
I connect any addin programmatically from within a COM addin, it
doesn't show any warnings anyway. I wonder if this is by design...

BTW how do I retrieve machnie-specific location of the Startup folder?

I think I should also consider obtaining the digital signature, because
I'm also going to provide an XML expansion pack, which unlike DOTs
doesn't work AT ALL if it's not signed. Is it a tiresome/costy
procedure? Can you give me a hint/link where to begin?

I'm interested with the troubleshooting capabilities you mentioned. Can
you tell me more about it? What are DOT benefits in tracking down
issues, I didn't quite understand.

[Cindy M -WordMVP-]

Hi Ignoramus,

Post by Ignoramus
BTW another consideration I forgot to mention is that COM add-in can be
connected to many Office applications, while DOT is Word specific.

Yes, although from what I've heard here and there, MS is moving away from
this capability.

Post by Ignoramus
BTW when
I connect any addin programmatically from within a COM addin, it
doesn't show any warnings anyway. I wonder if this is by design...

I believe so. And if you need to open Office files during automation and
want to suppress security warnings (and optionally macros) there's an
AutomationSecurity property for the Application object you can set.
Basically, the philosophy for COM Addins is: if the user has installed
it, anything "it" does should be OK. The security decision was made at
installation.

Post by Ignoramus
BTW how do I retrieve machnie-specific location of the Startup folder?

this varies from version to version and, if you're dealing with
administrated networks, you may not be able to extract it at all (again,
security consideration). Each version of Word has a default location
created at Setup; there used to be a KB article on this. Recently, it's
been under Application Data/Microsoft/Office. If the user changes the
setting, it can be picked up from the Registry HKCU or, if Word is
running from application.Options.DefaultFilePath(wdStartupPath)

Post by Ignoramus
I think I should also consider obtaining the digital signature, because
I'm also going to provide an XML expansion pack, which unlike DOTs
doesn't work AT ALL if it's not signed. Is it a tiresome/costy
procedure? Can you give me a hint/link where to begin?

It can be quite tiresome/costly. Verisign and Thwaite are the two big,
international authorities. Generally, people I know prefer dealing with
Thwaite. Some countries (nations) also provide certifications services.
If you're working for or within a corporation that has Windows 2003
Server, that can generate certificates that can be used within the
company. (Outside it, too, but the independent certification authority
isn't in the background.)

Post by Ignoramus
I'm interested with the troubleshooting capabilities you mentioned. Can
you tell me more about it? What are DOT benefits in tracking down
issues, I didn't quite understand.

This is more a benefit for the user than for you :-) If your Addin would
be "impolite" or misbehave, then Word would do things the user doesn't
like. We get two or three questions a day, in these groups, with "Why
does Word do..." - something Word simply doesn't do. The troubleshooting
steps always begin with: start Word in "Safe Mode". If the problem goes
away, then you're looking for an Add-in... Template Addins are the
easiest to track down AND to unload :-) Just had one the last 24 hours
where the user was seeing Normal.dot opened when Word closed. Turns out
the problem was an Omnipage Addin template.

Cindy Meister
INTER-Solutions, Switzerland
http://homepage.swissonline.ch/cindymeister (last update Jun 17 2005)
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 :-)

[Ignoramus]

Hi Cindy,

Thank you very much, you're the best! :)

Regarding the digital certificates. I wonder what is the role of the
authorities. As you previously said, the philosophy of the add-in
security is that if the user installs it, it should be ok. I agree
completely, but the consequence is that if the users installs my
add-in, they believe that it's my add-in and it does what they need.
The international authority can hardly add anything to this belief. Am
I right? So I think it should be ok just to provide a
not-internationally-authenticated (inside corporation) digital
certificate, just to work around the Office protection?

BTW, are you as good at the Smart Documents, the new feature of Office
2003? I find a little info on the net about this technology, but the
questions are many. :) Is this group the right place for these
questions too?