You are here: Office-Outlook.com  / Outlook Forum

VSTO 2005 SE vs Shared Add In?

Home » Outlook addins and plugins development » Developer Outlook add-ins
VSTO 2005 SE vs Shared Add In? [message #177334] Mon, 11 June 2007 13:24 Go to next message
Brian McCullough
Messages: 150
Registered: January 2007
Senior Member
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
RE: VSTO 2005 SE vs Shared Add In? [message #177501] Tue, 12 June 2007 00:44 Go to previous messageGo to next message
XL-Dennis
Messages: 518
Registered: August 2006
Senior Member
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/
Re: VSTO 2005 SE vs Shared Add In? [message #178040] Wed, 13 June 2007 08:37 Go to previous messageGo to next message
Brian McCullough
Messages: 150
Registered: January 2007
Senior Member
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


"pavan" <pavvu.akk@gmail.com> wrote in message
news:1181744466.758444.158680@x35g2000prf.googlegroups.com...
> On Jun 12, 1:24 am, "Brian McCullough" <nospammin...@nospam.com>
> wrote:
>> 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
>
Re: VSTO 2005 SE vs Shared Add In? [message #178481] Thu, 14 June 2007 07:30 Go to previous messageGo to next message
kenslovak
Messages: 13351
Registered: May 2006
Senior Member
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Brian McCullough" <nospammingme@test.com> wrote in message
news:e%23tkJDdrHHA.1404@TK2MSFTNGP03.phx.gbl...
>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
Re: VSTO 2005 SE vs Shared Add In? [message #181083] Mon, 11 June 2007 19:17 Go to previous messageGo to next message
hav
Messages: 18
Registered: June 2007
Junior Member
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
RE: VSTO 2005 SE vs Shared Add In? [message #181086] Tue, 12 June 2007 00:44 Go to previous messageGo to next message
XL-Dennis
Messages: 518
Registered: August 2006
Senior Member
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/
Re: VSTO 2005 SE vs Shared Add In? [message #181110] Wed, 13 June 2007 07:21 Go to previous messageGo to next message
pavan[1]
Messages: 60
Registered: August 2006
Member
On Jun 12, 1:24 am, "Brian McCullough" <nospammin...@nospam.com>
wrote:
> 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
Re: VSTO 2005 SE vs Shared Add In? [message #181111] Wed, 13 June 2007 08:37 Go to previous messageGo to next message
Brian McCullough
Messages: 150
Registered: January 2007
Senior Member
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


"pavan" <pavvu.akk@gmail.com> wrote in message
news:1181744466.758444.158680@x35g2000prf.googlegroups.com...
> On Jun 12, 1:24 am, "Brian McCullough" <nospammin...@nospam.com>
> wrote:
>> 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
>
Re: VSTO 2005 SE vs Shared Add In? [message #181126] Thu, 14 June 2007 07:30 Go to previous messageGo to next message
kenslovak
Messages: 13351
Registered: May 2006
Senior Member
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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Absolute Beginner's Guide to Microsoft Office Outlook 2003
Reminder Manager, Extended Reminders, Attachment Options
http://www.slovaktech.com/products.htm


"Brian McCullough" <nospammingme@test.com> wrote in message
news:e%23tkJDdrHHA.1404@TK2MSFTNGP03.phx.gbl...
>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
Re: VSTO 2005 SE vs Shared Add In? [message #184059] Wed, 27 June 2007 20:06 Go to previous message
hav
Messages: 18
Registered: June 2007
Junior Member
....although converting to c#/vb.net may not be too difficult if you
need managed code.
Previous Topic:How .NET Garbage collection is affected my Word PIA Add-In
Next Topic:Word 2000 add-in problem
Goto Forum: