Hi all,

What is best way to deploy Outlook 2007 Addins using visual studio
2008.

Can I use Setup project or I have to use ClickOnce?

Is there some good tutorials for deploying this solutions?

Is this addin a shared addin or a VSTO addin?

You can use either type of deployment, do you have objections to a ClickOnce
deployment?

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Ivica Muruzovic" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
>
> Hi all,
>
> What is best way to deploy Outlook 2007 Addins using visual studio
> 2008.
>
> Can I use Setup project or I have to use ClickOnce?
>
> Is there some good tutorials for deploying this solutions?
>

It it VSTO addin.

With ClickOnce deployment I have problem that Addin does not work on
some machines. One of errors was that FormRegion is not register, and
really in registry I could not found Key for Addin FormRegion. (On
some other machines same setup work perfect).
Also problem was too long loading of Addin when Outlook 2007 starts.
After long period of time I get error that was some problem in loading
Addin and Addin will be disable.


On Wed, 2 Jul 2008 09:53:44 -0400, "Ken Slovak - [MVP - Outlook]"
<(E-Mail Removed)> wrote:

>Is this addin a shared addin or a VSTO addin?
>
>You can use either type of deployment, do you have objections to a ClickOnce
>deployment?

Startup time has nothing to do with the installer. It's a function of how
long your addin initialization takes plus various overheads for managed
code.

If your addin is the first managed code application to run in that Outlook
session the CLR has to be started up. Your addin has to be JIT compiled and
put into the cache if it wasn't already JIT compiled and in the cache. Those
operations take some time. You should notice much faster startups if you
close Outlook and then re-open it right away while the addin is still cached
and the CLR is running.

For VSTO addins there's additional overhead of starting the VSTO runtime.

If the registration of things such as COM addins or form regions isn't
working you need to see what's different about where it works and where it
doesn't. User installation rights, permissions on different sections of the
registry and where the addin is being installed (HKCU or HKLM) must be
investigated. In general VSTO addins require admin permissions to install.

For VSTO addins you also have the consideration that the assemblies must be
strong named and must have full trust to run. You need to check whether or
not the CASPOL settings for full trust have been applied to your addin
assemblies.

You also need to check the Fusion logs to see what's failing to load and
why. See
http://blogs.msdn.com/vsod/archive/2...-failures.aspx
for information on how to do that.

Your problems most likely will not be solved by switching installer types.
They will haunt you with a setup project installer until you find out why
your current installer is failing in some cases or why the loads are
failing.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"Ivica Muruzovic" <(E-Mail Removed)> wrote in message
news(E-Mail Removed)...
> It it VSTO addin.
>
> With ClickOnce deployment I have problem that Addin does not work on
> some machines. One of errors was that FormRegion is not register, and
> really in registry I could not found Key for Addin FormRegion. (On
> some other machines same setup work perfect).
> Also problem was too long loading of Addin when Outlook 2007 starts.
> After long period of time I get error that was some problem in loading
> Addin and Addin will be disable.

Thank you for informations

I will investigate my problem

On Thu, 3 Jul 2008 09:53:00 -0400, "Ken Slovak - [MVP - Outlook]"
<(E-Mail Removed)> wrote:

>Startup time has nothing to do with the installer. It's a function of how
>long your addin initialization takes plus various overheads for managed
>code.
>
>If your addin is the first managed code application to run in that Outlook
>session the CLR has to be started up. Your addin has to be JIT compiled and
>put into the cache if it wasn't already JIT compiled and in the cache. Those
>operations take some time. You should notice much faster startups if you
>close Outlook and then re-open it right away while the addin is still cached
>and the CLR is running.
>
>For VSTO addins there's additional overhead of starting the VSTO runtime.
>
>If the registration of things such as COM addins or form regions isn't
>working you need to see what's different about where it works and where it
>doesn't. User installation rights, permissions on different sections of the
>registry and where the addin is being installed (HKCU or HKLM) must be
>investigated. In general VSTO addins require admin permissions to install.
>
>For VSTO addins you also have the consideration that the assemblies must be
>strong named and must have full trust to run. You need to check whether or
>not the CASPOL settings for full trust have been applied to your addin
>assemblies.
>
>You also need to check the Fusion logs to see what's failing to load and
>why. See
>http://blogs.msdn.com/vsod/archive/2...-failures.aspx
>for information on how to do that.
>
>Your problems most likely will not be solved by switching installer types.
>They will haunt you with a setup project installer until you find out why
>your current installer is failing in some cases or why the loads are
>failing.