Help! Strange error message.

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi
I am trying to deploy a COM Add-in for Outlook for an enterprise
environment. It runs fine on my machine. When I take the setup files that
are generated by VS.NET 2005 to another computer, either:

1) They have no problems with the install, yet the Add-In isn't shown in
Outlook.

2) I get an error message that says “This advertised application would not
be installed because it might be unsafe. Contact your administrator to change
the installation user interface option of the package to basic.â€

Can anyone tell me what might be going on here? I've searched all over, and
seen that condition 2) has to do with group policies defining the GUID my
project is using as something called "advertised". Is there a way to get
rid of error 2) by changing the GUID to something that is non-advertised?

Thanks very much for your help
-Josh
 
Hi again
I figured out that to get rid of the error message, I could run the msi
installer with the /qb switch. This makes the installers interface "basic"
(just one small dialog box), as opposed to "advertised" (with multiple
screens and graphics) which apparently has something to do with security
imposed by group policy settings. I'd really like to have users see my
install screens if possible. Can I?

In any case, the add-in still won't run. It actually does show up in the
list in Outlook at Tools -> Options -> Other -> Advanced Options -> COM
Add-Ins, but the box next to it isn't checked. If you do put a check in it
and click OK, as soon as you re-open the list, the check is gone.

Does this have something to do with me not specifying correctly that the
Add-In should automatically run at startup?

Thanks again
-Josh
 
If a group policy is involved you will need to get it changed for what you
want.

Your symptoms could be any number of things. You might not have checked or
deployed all of the dependencies or requirements for your addin. Many of
those files are included when you have VS installed but aren't there for
users. Some examples are (aside from the Framework): extensibility.dll,
stdole.dll, the PIA's and any other dependencies.

If the registry after installation shows LoadBehavior as 3 the addin is set
to start when Outlook starts. If there is a load error your addin may either
be disabled (Help, About, Disabled Items) or LoadBehavior becomes 2. If the
after installation setting is correct then I'd suspect either a missing dll
on the target machines or some security problem.

What version of Outlook are you supporting? What version is on your dev
machine? What OS is being deployed to? What are you deploying with your
project? Is this a shared addin or a VSTO addin? If a shared addin are you
using a shim?
 
Hi Ken

Thanks very much for taking the time for helping me out with this.

My Add-In isn't showing up in the Disabled Items box. It is, however,
changing it's LoadBehavior entry in the registry from 3 to 2. I notice on
client computers now a message that actually does report that it is failing
to load. Is there any easy way to figure out why? (I'm using the
IDTExtensibility2 method rather than VSTO).
There is a file in the VS.NET generated Setup files for my project that I
have marked "excluded", because it was giving me an error on setup. I can't,
however, figure out how to get it off the dependency list! I don't know what
part of the code needs it. However, when I choose to "open" it with the
resource viewer and look at the resulting hex, I see the name "stdole2.tlb"
in there. My IDTExtensibility code also uses the line "Imports
Extensibility", the two culprits you mentioned.
Do I need to somehow include those two files in the Setup project so my
users will get them?

When it comes to security policies, I'm afraid I don't know a thing. I
heard there is a .NET Configuration Applet from the SDK that you could use in
version 2.0 of the framework to edit security policys for code. Do I
understand right that if I use it, I can somehow change the level of trust my
Add-In is granted on other user's machines?

I'm writing for Outlook 11 (2003) and XP, which I have both of on my dev
machine. As I said, I'm not using VSTO. I am deploying just what VS.NET
plopped into my setup project for me. In my "setup" project's "Detected
Dependencies" folder is:
Version 2.0.50727 of the .NET framework, even though my machine has 3.0
installed (not sure why VS.NET isn't using 3.0, unless it's because I started
the project when it was version 2),
Interop.OUTLOOKADDINLib.dll,
Interop.Redemption.dll,
Microsoft.Office.Interop.Outlook.dll,
Microsoft.Vbe.Interop.dll,
office.dll,
olkaddin.dll,
and Redemtion.dll.

I am not using a shim (it's a new concept to me). I also do remember
installing the office PIAs, although I'm afraid I'm going to have to claim
ignorance here, as I'm still not 100% clear as to what they do for me...I
installed them because of a compiler error that I eventually figured out they
would resolved.


Thanks again for the help!

-Josh
 
My guess is that you would need to deploy extensibility.dll and stdole.dll
with your application to the installation folder. That's usually necessary
since Outlook 2003 doesn't install those dll's. You will need to check for
the installation of the PIA's for Office and Outlook and to deploy the
Redemption dll, which should be marked as self-registering. You will also
need to check for installation of the Framework. I'd be less inclined to
suspect security settings in this case.

The pre-requisites and requirements can be checked during installation and
using a bootstrapper can install or download any missing elements. If you
want to exclude a dependency you just right-click on it and select Exclude.

I don't have a handy link to shared addin deployments although you can
probably find that using google. Here's a link to deployment for VSTO
addins, the sections on the bootstrapper and requirements/pre-requisites is
pretty much what you will need except for the VSTO specific stuff like the
runtime: http://msdn2.microsoft.com/en-us/library/bb332051.aspx

Shimming is a way of giving your managed code addin its own AppDomain. If
you don't do that then you join in the default AppDomain with any other
unshimmed addins. The implications of that are if one addin in that
AppDomain crashes then Outlook will most likely disable all of them in that
AppDomain. If you are in your own AppDomain then you are isolated from that.
There's a new shim wizard that supports the Ribbon for Outlook 2007 or you
can use the previous version of the shim wizard if you don't need Ribbon
support. Whether or not you decide to shim your code is up to you.

In general you also should use strong naming with a code signing certificate
with your project and then after building sign your DLL and the resulting
deployment with your certificate.
 
Back
Top