My case is :
I developed an outlook add-in on visual studio 2013 then build to the MSI installation by InstallShield.
and setup registry in my MSI config file follow 2 way below :
HKEY_CURRENT_USER :
+ HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins
+ HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\FormRegions
HKEY_LOCAL_MACHINE :
+ HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\Addins
+ HKEY_LOCAL_MACHINE\Software\Microsoft\Office\Outlook\FormRegions
I created outlook add-in with the vsto file named 'abc.vsto'
For the first installing, it work fine.
After that i changed the name of vsto file from abc.vsto to def.vsto for creating new MSI installation.
But there are some issues happen after i installed add-in from the new one.
It's always show Formregion with empty control, after three or four time restart outlook, it work well.
maybe there are some encounter happen with two vsto file or something wrong with registry.
I realized that the outlook always creating new *.ost file which named *(2).ost after everytime restart that make duplicating ost file.How can i control generate *.ost process of outlook or why is this happen ?
I use this function for getting current outlook email user but it always return null value.
Globals.ThisAddIn.Application.Session.CurrentUser.AddressEntry.GetExchangeUser();I don't know if this issue related to question 2 or not cause if I remove all *.ost file then restart outlook, in this case, the new *.ost file
was auto generated and add-in work well.
Related
We have developed VSTO add-in for Word, Excel and PowerPoint. Recently, we changed the friendly name (FriendlyName) and description (OfficeApplicationDescription) of the add-ins in csproj project files.
Our aim is to change the name and description that will be displayed in the Manage add-ins screen in Office apps. After changing the project file, if I run the code from Visual Studio, I can see my changes reflected in the Manage add-ins screen. However, when we install the add-in in non-development machines, we noticed that still old name and description is displayed.
I confirmed that the manifest file in the non-development machine has my updated name and description, but Office still shows the old values.
I tried clearing cache in the below folders:
%LOCALAPPDATA%\Microsoft\Office\16.0\Wef\
%userprofile%\local Settings\Application Data\assembly
Still the issue occurs.
We've created an Outlook add-in which integrates our custom CRM with Outlook. A command button is added to messages in read and compose mode. A function file is called on the button click.
The add-in manifest passes validation and installs properly on all machines. However on Outlook 2016 desktop (only) we are seeing an error on some machines. The exact error message says: “We’re sorry, we couldn’t access [NCS Outlook Add-in]. Make sure you have a network connection. If the problem continues, please try again later.” ([NCS Outlook Add-In] is the name of our add-in.)
Note that this message appears IMMEDIATELY after clicking the add-in command button. It does not first say “[NCS Outlook Add-in] is working on your request” like it add-ins do when an error has occurred.
We have tried Outlook logging and haven't found anything useful in the logs. We've checked settings and disabled other add-ins. We have also tested across machines with user accounts. The same user will have the error on one machine and not the other. In short, it seems that the error is machine specific and not profile related.
Version of Office 365 installed: 1705 (Build 8201.2209).
We experienced this exact behavior in Outlook 2016, the solution was to enable protected mode for the restricted and internet zones.
The easiest way to change this is in IE.
In Internet Explorer, click the Tools button, and then click Internet Options.
Click the Security tab, and then select the Restricted Sites Zone.
Select the Enable Protected Mode check box, and then click OK.
Restart Internet Explorer.
Here is a little more information:
https://support.microsoft.com/en-us/help/2761180/apps-for-office-don-t-start-if-you-disable-protected-mode-for-the-rest
Try this:
1) Close Outlook
2) Rename the folder C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook
to C:\Users\%USERNAME%\AppData\Local\Microsoft\Outlook.OLD
(Where %USERNAME% is current User Name.)
3) Start Outlook, Setup User Profile
4) Add/Test Add-In.
If that works, then something broken on old Outlook profile. But if same problem: Exit Outlook, delete the Outlook folder and rename Outlook.OLD back to Outlook.
I ran into this exact same problem after uninstalling Visual Studio 2015 on my development machine. (I had been using Visual Studio 2017 for Outlook add-in development.)
The problem went away as soon as I reinstalled Visual Studio 2017. The Outlook 2016 installation had nothing to do with the problem, I never changed Outlook or its profile at all.
This would indicate that the problem is somehow related to the SDK tooling on the machine...perhaps something to do with the .Net framework?
If I ran into this problem on a customer machine I would try reinstalling or repairing the .Net framework, or perhaps reinstalling Outlook (assuming it contains some add-in tooling that is broken.)
Just passing this on in case it helps anyone else.
This is a very strange situation that I am in; scratching my head for answers.
I have developed an outlook addin that works perfectly on my dev machine and on about 90 % of the clients machines.
The load behavior of the addin is 3.
On 10% of the users, outlook starts up without loading the addin despite the load behaviour being 3. The user can manually make the addin active by going to the addin manager on outlook but after a restart this addin reverts back to being inactive bbut load behavior never changes from 3.
I used Install Shield LE to package this addin. I don't even know where to debug anymore, I tried changing different load behaviour values but still the same outcome. The addin just won't load on startup with this set of users.
The company uses ZenWorks to automatically install the addin on all the PCs from the MSI i generate using install shield.
One weird thing is, If i go to the installation directory of the addin and install the addin using the .vsto deployment file, it works and gets loaded on outlook (but thats makes it two addins installed).
I also checked the Resiliency section on the registry and the addin isn't there.
I have faced this issue. To solve this, you need to manually delete the registry entries from the following path.
Open registry editor and go to HKEY_CURRENT_USER\Software\Microsoft\Office\Outlook\Addins\<Your add-in> and change the LoadBehavior to 3.
If the above registry entry is not found, then look for HKEY_CURRENT_USER\Software\Wow6432Node\Microsoft\Office\Outlook\Addins\<Your add-in> and change the LoadBehavior to 3.
Go to HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Outlook\Resiliency – remove the REG_BINARY keys found in DisabledItems and CrashingAddinList
where 15.0 is for outlook 2013.
If you are using 2010 outlook, replace 15.0 by 14.0 and for Outlook 2016 replace 15.0 by 16.0
Hope this helps.
While I was adding controls to a VSTO MS Word template in Visual Studio, the copy of Word that was serving as the form editor crashed taking Visual Studio down with it. When I restarted Visual Studio, I discovered that while the controls I'd spent the last several hours inserting and naming were preserved in the ThisDocument.Designer.vb file the associated .dotx file apparently was not autosaved because none of the new controls were on it.
Is there any way to restore the controls to the .dotx file from the designer; or am I stuck with having to redo all of the lost work?
I'm using VSTO for Office 2007 if it matters.
If you have built your application at least once then you can copy the .dotx file created in your bin folder.
I am using the Visual Studio 2010 setup to create an installer for my application. From the File system Editor i have selected one of the two primary output files that have been created in my solution. I have right clicked and created a shortcut for my executable. I have dragged and droped the shortcut into the User's Program Menu. I build the installer and everything completes successfully. I run the installer and everything runs successfully. Now i proceed to double click on the shortcut and the installer re-runs and fails!!!. I have checked the shortcut and it is different from the one i have manually created to compare. The Target is greyed out. Any help would be greatly appreciated!!!
When launching an application through an advertised shortcut, Windows Installer verifies if the application resources are intact. If one or more resources are missing, Windows Installer reinstalls them automatically using the cached MSI. This is why the second installation is performed.
Shortcuts created in Visual Studio are advertised, so a repair is triggered if some of your installed files are missing.
To determine what triggers the repair you can try this:
after receiving a “preparing to install” message open Event Viewer (you can search it in the Start menu or launch “eventvwr.msc”)
go to “Windows Logs” -> “Application”
look for “MsiInstaller” information messages which have this form:
Event Type: Warning
Event Source: MsiInstaller
Event ID: 1001
Description: Detection of product '{1F7D16F0-836D-4CE4-9123-D30B2F24A17B}', feature 'FeatureId' failed during request for component '{068153F4-B9E0-4745-9A47-833764D9D60C}'
The GUIDs will be different on your machine, but they can help you identify which component is causing the problem. The first GUID is your package ProductCode and the second one is for the problematic component. Try creating an installation log and see why the component is not installed correctly.
This ended up being an issue with the registry hive. The Visual Studio 2010 Registry editor would allow me to specify values in 'HKEY_USERS(64)\S-1-5-20\Fileopen. This however was the reason for the error above. That is, you can't have values in this part of the registry when it is being generated using setup and deployment from Visual Studio 2010. I moved the values to exist under local_Machine and the short cut work like a charm.