VSTO acceptance question...

[jojobar]

Hello,

I have to develop a ms word add-in for our product. After doing some
research, I found that there are many options. The easiest being
developing with VSTO.

Before starting to develop with VSTO (compared to old fashioned C++/VB
add-in), I have a couple of questions.

It seems that VSTO is only supported on Office 2003 products. Is it
okay to develop add-ins that work only on Office 2003? What percentage
of people have upgraded to 2003? Will these people migrate to 2003 or
higher later?

I know that there may not be a clear answer to these questions. I just
want to know if you have (or planning to) embraced VSTO for your
product. If so, what are your reasons.

Thanks
jojobar

 

[Cindy M -WordMVP-]

Hi Jojobar,

I have to develop a ms word add-in for our product. After doing some
research, I found that there are many options. The easiest being
developing with VSTO.

Before starting to develop with VSTO (compared to old fashioned C++/VB
add-in), I have a couple of questions.

It seems that VSTO is only supported on Office 2003 products. Is it
okay to develop add-ins that work only on Office 2003? What percentage
of people have upgraded to 2003? Will these people migrate to 2003 or
higher later?

Only you can really answer the question about whether an Addin developed
only for Word 2003 is worthwhile. Is the tool something people would
need in other versions? Have you surveyed your potential clients?

FWIW, VSTO is *NOT* an true addin. The technology is document-specific
and only available in the document (or document attached to a template).
VSTO is also location-specific. If you go the document-from-template
route, then the VSTO capabilities are going to be lost as soon as the
user saves the document (unless the solution updates the document to
"see" the assemblies).

If what you really intend is to provide an Addin that's available to the
user all the time, VSTO is *NOT* the technology you want to use. In this
case, you still have to develop a traditional, COM-Addin, with all the
problems that implies. (DLL-Hell if you develop in COM, needing a Shim
if you develop in .NET.)

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

 

[jojobar]

Thank you for taking time to answer my query. I think COM-Addin is the
way to go right now.

I do believe people will upgrade to Office 11 (or 12 in the near
future), but they surely will wait until they have to...

 

[Cindy M -WordMVP-]

Hi Jojobar,

Thank you for taking time to answer my query. I think COM-Addin is the
way to go right now.

I do believe people will upgrade to Office 11 (or 12 in the near
future), but they surely will wait until they have to...

In either case, there's no reason they can't continue to use a
COM-Addin. The only thing you'd need to take into account, if you're
looking forward towards the version currently in beta, is how the user
interface is changing (see the inforamtion on microsoft.com and in the
various blogs available there).

Generally speaking, you'll want to structure your code so that you can
change from creating traditional toolbars/menus to the new "Ribbons",
without interfering in how the actual tool works. IOW, divorce the UI
you create from the functionality you provide.

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