VSTO 2005 SE vs Shared Add In?

[Brian McCullough]

Hello,

According to the following article, using VSTO 2005 SE offers advantages
over using the out of the box Shared Add In project template (stated about
3/4 of the way down the document in the "Using COM Add-ins to Modify the
Fluent UI" section):

http://msdn2.microsoft.com/en-us/library/ms406046.aspx

"Among other advantages, add-ins that you create by using Visual Studio 2005
Tools for Office Second Edition run in separate application domains, and the
programming model for these add-ins is simpler, and more maintainable, than
that used by the shared add-in template."

This is just a general statement. I am wondering the "why" behind each of
these statements. For example, why is VSTO more maintainable? What
advantages does running under a separate application domain have?

I am also intersted in finding out the disadvantages of using VSTO vs the
Shared Add In template. One I can think of off the bat is that it requires
the download and installation of a separate SDK. Any others?

TIA

Brian

 

[hav]

Hey Brian,
I am wondering the same thing mate. I've started working on a project
written in VB.NET which creates an add-in, but we are definately
thinking of going VSTO if its good. All I know is A) MS warns us off
of "Serious Development using VSTO" (has this changed in V.2?) and B)
Add-ins are horrible because the Word API is built using COM, and we
have to talk to unmanaged code from .NET which has its drawbacks. In
fact, when the clients of this piece upgrade to Word 2007 they'll be
needing another change...
Anyone else?
Henry

 

[XL-Dennis]

Hi,

With a Shared Add-in we need to "shim" the solution so it will run in its
own appdomain ( isolation), i e use a so called customized loader. With VSTO
this is not necessary as it exist already a VSTOLoader that takes care about
it.

The other statement refer probably to that it's easier to access, for
instance, Excel's object model through VSTO then via a Shared Add-in and
where some objects are not available.

But keep in mind the following when it comes to VSTO:
Put another extra layer between the add-in and the host application which
affect the overal performance.
The setup is more complicated as we need to to use CAS.

---------------
With kind regards,
Dennis
Weekly Blog .NET & Excel: http://xldennis.wordpress.com/
My English site: http://www.excelkb.com/default.aspx
My Swedish site: http://www.xldennis.com/

 

[pavan]

Hello,

According to the following article, using VSTO 2005 SE offers advantages
over using the out of the box Shared Add In project template (stated about
3/4 of the way down the document in the "Using COM Add-ins to Modify the
Fluent UI" section):

http://msdn2.microsoft.com/en-us/library/ms406046.aspx

"Among other advantages, add-ins that you create by using Visual Studio 2005
Tools for Office Second Edition run in separate application domains, and the
programming model for these add-ins is simpler, and more maintainable, than
that used by the shared add-in template."

This is just a general statement. I am wondering the "why" behind each of
these statements. For example, why is VSTO more maintainable? What
advantages does running under a separate application domain have?

I am also intersted in finding out the disadvantages of using VSTO vs the
Shared Add In template. One I can think of off the bat is that it requires
the download and installation of a separate SDK. Any others?

TIA

Brian

Just to add to what Dennis has to say and clarify on why shim is
needed: As already you know shim is required to run the add-in in a
seperate app domain. And why should it be necessary? Because if we
dont do that and say your addin and my addin are installed on the same
m/c, then a crash in my addin will crash yours and vice versa. To
avoid this we need to have different app domians for addins.

Hope this helps

Regards,
Pavan

 

[Brian McCullough]

I may be experiencing this exact problem (with the sharing of app domains).
I know this is outside the scope of my original question, but...

If I have a COM Add In written in VB6 for Office XP (i.e. Outlook, Word,
Excel, and/or PowerPoint), can I use this "Shim" approach?

Thanks!

-Brian

 

[Ken Slovak - [MVP - Outlook]]

VB6 addins aren't managed code, they are intrinsically in their own
application space. There are no shims for VB6 addins and can't be.

 

[hav]

....although converting to c#/vb.net may not be too difficult if you
need managed code.