Deploy Office AddIns using Side-by-Side

[may]

Hi,
I'm wondering can I use side by side deployment to deploy and install my
Excel addins. The AddIn has been developed in VBA and needs to be installed
into Excel along with another application installation. I have written an
application to install the addin previously which requires registry
installation but I want to avoid this if possible in the future. If I do it
using side-by-side and manifests how does Office 'know' to load my Add-In at
start up. Any tips would be greatly appreciated.
Kim

 

[XL-Dennis]

Hi may,

I'm not sure if I understand Your case correctly but I will give it a try.

Add-ins need to be registrated in the Windows registry in order to let Excel
knows it exist. The best solution is to use a tool like Wise to create an
installation package so that the add-in is registrated upon installation.
However, Wise and similar tools are quite expensive and can also be quite
demanding in order to use them.

Jan-Karel Pietersen has recently made a write up about add-ins and the
following section may be of interest:
Create a setup utility
http://www.jkp-ads.com/Articles/DistributeMacro10.htm

One approach would be to let the other application 'install and activate'
the add-in (based on the above mentioned article) when it first is launched.

With kind regards,
Dennis

 

[may]

Thanks Dennis,
So are you saying it is not possible to install an addin without registering
it in the registry? I thought perhaps it might be possible using side-by-side
deployment and manifest files to specify its location. Does Visual Studio
2005 Tools for Office not enable this? I have already built a small app to
install addins but it writes entries to the registry. We want to get away
from this because writing to the registry requires Admin rights etc.

 

[XL-Dennis]

Hi May,

If we are talking about an Excel developed add-in (file extension xla and
developed with VBA) then one possible way is to 'load' it via the other
application without force a registration process. What You do is simple to
open it as a ordinary Excel file via the Open command.

Excel only offer a COM Interface to communicate via and therefore both COM
Add-ins and 'managed' COM Add-ins need to be registrated before Excel is
aware that they are available.

I'm not sure if it would be doable or not via VSTO. At present I have the
impression that VSTO works good with Outlook but not so well with Word or
Excel.

Let me know if the above make any sense to you or not. Let me also know more
about Your development platform.

 

[may]

The problem as you point out, is making Excel aware that the AddIn is
available. We would be developing our AddIns using VSTA or VSTO. As I'm new
to both of these I don't really know their strengths and limitations. I think
I'll need to download evaluations. If COM is the only way to go then I'll be
stuck with the registry.
Thanks for your help

 

[Cindy M.]

Hi =?Utf-8?B?bWF5?=,

So are you saying it is not possible to install an addin without registering
it in the registry? I thought perhaps it might be possible using side-by-side
deployment and manifest files to specify its location. Does Visual Studio
2005 Tools for Office not enable this? I have already built a small app to
install addins but it writes entries to the registry. We want to get away
from this because writing to the registry requires Admin rights etc.

The problem as you point out, is making Excel aware that the AddIn is
available. We would be developing our AddIns using VSTA or VSTO. As I'm new
to both of these I don't really know their strengths and limitations. I think
I'll need to download evaluations. If COM is the only way to go then I'll be
stuck with the registry.

A COM Add-in must always be registered, whether it's made using managed code or
not. The key is how the COM applications are designed - not what language was
used to create the Add-in.

Currently, VSTO can only create COM Add-ins for Outlook. In the new version
(currently CTP) it can create Add-ins for other Office *2007* applications. VSTO
for Word and Excel is actually more a substitute for document-specific code,
replacing embedded VBA with managed code DLLs. This kind of VSTO solution does
*not* need to be registered. It works with cas and manifests. But it is
document-specific.

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

 

[may]

OK right, so I could use VSTO to write replacements for older VBA addins. If
they were written as managed dlls then I can deploy with manifests etc? If
this is so then how do I make Excel aware that these dlls are available and
should be loaded (if it's not registered) when Excel is started? Hope my q's
makes sense.

 

[Cindy M.]

Hi =?Utf-8?B?bWF5?=,

OK right, so I could use VSTO to write replacements for older VBA addins. If
they were written as managed dlls then I can deploy with manifests etc? If
this is so then how do I make Excel aware that these dlls are available and
should be loaded (if it's not registered) when Excel is started? Hope my q's
makes sense.

They make sense...

As I said, VSTO 2003/2005 is document-specific. That means the customizations
are available only while in that one particular file. Add-ins are (usually) in
the context of the entire application - the commands are always available. Yes,
you can sink events to make them available only under certain circumstances. If
this is what you have, then it could be a candidate for a VSTO Excel solution.

But yes, a VSTO solution will have
- the file with which the code is associated
- the managed dll(s) containing the solution code
- sometimes a manifest (especially if the part of the solution is deployed
in a network location)

The client machine must have
- the appropriate version of the .NET Framework
- Office 2003 PROFESSIONAL
- the PIAs installed in the GAC
- the VSTOR (vsto runtime)

This last is what takes care of linking Excel (or Word) to the managed code.
Office 2003 pro "knows" to check whether a document contains certain things
related to VSTO. If they're present, the Office app calls the vsto
loader/runtime, which takes the information (manifest or local paths) and loads
the dlls.

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

 

[may]

Thanks so much! Just one last thing - if I want to create something which is
not document-specific but rather application wide then VSTO doesn't seem to
be the way to go - for this scenario I'm stuck with COM addins which require
registration in the registry - is this correct?

 

[Cindy M.]

Hi =?Utf-8?B?bWF5?=,

Thanks so much! Just one last thing - if I want to create something which is
not document-specific but rather application wide then VSTO doesn't seem to
be the way to go - for this scenario I'm stuck with COM addins which require
registration in the registry - is this correct?

That's correct, unless (coming full circle) you create an Excel- or
Word-specific Add-in that's stored in an application file (IOW not a dll). An
xla (I think) for Excel; a Word template (*.dot) loaded as an Add-in for Word.
No registration required in this case. You might want to ask the Excel
specialists in Excel.programming for more information.

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

 

[XL-Dennis]

May,
In my previously post I did mention that xlas can be 'loaded' by using a
open statement. It's not the recommended approach but in view of the issues
with administrative rights on the targeting computers it's at least a
solution.

The following link is to an article about loading xla from VB 6.0:
Activate add-ins: http://www.excelkb.com/article.aspx?id=10040&cNode=7X0G0W

Let me know if You want an example with .NET platform.

Cindy:
I sincerely hope it's OK to reply on Excel-specific questions in this
newsgroup as well. I believe I'm fully capable of doing that and unlike Your
fellow MVP Excel geeks in the MSFT's newsgroups I both like and use VB 6.0,
VB.NET and VSTO <vbg>

 

[may]

Thanks guys for all your help.
-Kim

 

[Cindy M.]

Hi Dennis,

I sincerely hope it's OK to reply on Excel-specific questions in this
newsgroup as well. I believe I'm fully capable of doing that and unlike Your
fellow MVP Excel geeks in the MSFT's newsgroups I both like and use VB 6.0,
VB.NET and VSTO <vbg>

Certainly not a problem for me I'm just so used to there NOT being anyone
around who knows Excel in any detail...

Have at it!

Cindy Meister

 

[XL-Dennis]

Cindy,

Great and I expect that I will be around this newsgroup for a longer time.