I created an Outlook addin. It does nothing special, just adds a menu with one menu item. I followed the installer creation tutorial from http://blogs.msdn.com/b/mcsuksoldev/archive/2010/10/01/building-and-deploying-an-outlook-2010-add-in-part-2-of-2.aspx.
It installs and works properly on a normal windows desktop installation, but I cant figure out how to do it in a Citrix XenApp environment. I can install it using the installer in the same profile where the Outlook is installed successfully. But when Outlook is run, it is in the "Inactive Application Addins" section when I view it from the Trust Center menu, and it wont activate properly. If I open the Manage COM Addins menu, it displays "Load at Startup" as my addin's Load Behavior. If I try to activate it manually from this menu, nothing happens, and if I open it again, Load Behavior will change to "Not Loaded. The Managed Add-in Loader failed to initialize."
Anyone encountered this or something similar before? Thanks in advance.
If it's installing but inactive then it's probably throwing an exception upon startup.
I'd wrap all of your startup code (ThisAddIn_Startup function inside your ThisAddIn.cs) inside a try {} catch {} and log all errors out to disk so you can see why outlook is disabling your addin.
Have you tried setting the VSTO_SUPPRESSDISPLAYALERTS environment variable to see if you can get outlook to give you more info?
(BTW I have found outlook VSTO's to be flaky. Sometimes they just refuse to install and work.)
Related
I develop an Outlook plug-in in C# using Addin express. The installer is based on Wix using ClickTwice:) for deployment and upgrades. We have a seamless upgrade process from our plug-in where new versions are downloaded automatically.
However, because Outlook is open when the installation process is launched, we receive a pop-up once download is complete notifying the user to close Outlook. See screenshot available from link:
Application in use warning
Our users are very non-technical, and they will most likely close this message by clicking cancel or the X button, which cancels the installation. We are already able to show our own message to the user explaining what to do, but we would really like to hide the automated message so that our users don't get confused.
Is there any way to disable this message or to automatically select an option for the user without the pop-up appearing? Our installer configuration file is Product.wxs.
Any help would be appreciated.
Thank you!
The dialog doesn't come from WIX. Instead, you may take a look at the Preferences of your ClickTwice solution. By default, you may see the following picture:
So, there you may configure to not display any dialogs.
First let me get this stuff out of the way:
This happens with my own addin, as well as another third party VSTO add-in, so I don't think I'm doing anything incorrect
.net 4.0. VSTO runtime 10.0.50701
Windows 8. Also tried Windows 7
I am using the |vstolocal suffix in the HKLM registry for the addin
I have also tried adjusting the 'program files' paths in the registry here: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion to point to my new 'F:' location, and that didn't change any behavior
Here are the steps I'm taking:
Create a new volume on a separate disk other than C:. I called mine 'F:'
Add the program files structures F:\program files and F:\program files (x86)
Install your VSTO addin (I'm using Outlook but it will happen with Word too) to "F:\program files (x86)" instead of the 'C:' drive
Launch Outlook.
Result is this dialog:
According to this, I shouldn't be getting this since its an all users install (see the Inclusion List section):
Is this a Microsoft issue? I realize I can add to the Inclusion myself however then I would be subscribing to more of a per-user approach, and that seems like a bad approach. Is this coming up because anything other than the 'real' program files folder cannot really be trusted by VSTO loader?
The dialog window belongs to the ClickOnce installer. But the link goes to the Windows Installer section in MSDN.
It is up to you where to install the add-in, there is no need to use the Program Files folder.
Make sure that you did all the steps described in the Deploying an Office Solution by Using Windows Installer article. It describes all the required steps for creating add-in installers.
I recently went through the same thing, i got this when i just published the vsto from vs2015. I tried using installshield, yielded the same issues, eventually i switched to wix installer, now i don't have any update checks running and its a clean install. These are some customization updates and our client actually had a firewall blocking it so the install failed. Try wix it worked great for me. Hopefully you don't end up with my current issue of not seeing the add-in if i am not running outlook as Administrator, driving me nuts, good luck.
Hopefully this is placed in the right area, but I seem to be having an issue with a registered dll.
Our main application is written with Power Builder Version 11, and through various objects, we are able to call registered C# .dll's
The C# .dll is created in Visual Studio 2008 and is installed via an installer that someone else in the building made. When a user runs the installer, they are given the option to register it for everyone or 'Just Me'
The .dll is installed successfully and the user that did the install is able to run the Power Builder application and call the functions inside the .dll.
The issue that arises is that any other user that runs the Power Builder application is greeted with a message box that says: Unable to connect to: [my dll].
I tried to re-register the .dll (using Regasm) but that doesn't work. I have confirmed that the folder is in the PATH System Variable.
The only solution I found was to uninstall the .dll from the Control Panel and re-install it from scratch. But, the same issue arise after the install.
What could the issue be? I'm starting to think that it has to be a rights issue but I can't be 100% positive.
My installer needs to open a file browse dialog. As there is no file browse dialog provided by WIX I have written a C# dll containing a method to invoke the standard OpenFileDialog when called by a Custom Action. However while this works fine in Win2003 the Custom Action just hangs when run on Windows 7. It seems to get as far as the ShowDialog() call then stop. As a test I have written a separate Windows Forms app with a single dialog and button to invoke the OpenFileDialog and, as expected, that works fine. I just can't get the OpenFileDialog to appear from within my msi!
I suspect it may be a security thing so I ran the installer from msiexec opened as Administrator but with no difference!
Does anyone have any ideas how to fix this?
Many Thanks.
// create a new thread with appropriate apartment state to launch UI
OpenFileDialog fileBrowser = new OpenFileDialog();
Thread worker = new Thread(fileBrowser.Show);
worker.SetApartmentState(ApartmentState.STA); // <-- here is the magic code
worker.Start();
worker.Join();
When I attempted this I found it was popping up behind the other MSI windows. Until I figured this out, it looked just like a hang.
For this and a whole heap of other reasons, I ended up writing a bespoke install mechanism and ditching MSI. Much friendlier on the user and their system in the end.
I have an outlook addin that I have been developing for some time now, and am experiencing a problem. If I have a computer with two 'administrator' users (call them User A and User B), the addin installs and runs just fine as long as the same user tries to run it. In other words, if User A installs the addin, then User A has no problem using.
The strange behavior comes in when we see the following scenario: User A installs the addin (for all users), User B launches outlook and observes that the addin is trying to install itself yet again. If User B cancels out of the 'install', he can then go and use the addin just fine.
Right now, I use office's registry key propagation to do an 'all users' install,
and I inspected the registry for any duplications and found none. I even used the officeins tool to try and detect if there was any duplication going on, and found none.
I'm really bewildered as to why the addin would try to install itself over and over again. Does anyone know why this might be happening?
This has to do with junk being absent from the registry (at least in my case). Using the 'Event Viewer' in windows will allow you to look at the MSI installer logs that point to what registry key was missing.
Here is a great article about installing an outlook addin for all users:
http://blogs.msdn.com/mshneer/archive/2007/09/04/deploying-your-vsto-add-in-to-all-users-part-i.aspx