Problems with the Outlook VSTO 2010 plugin working on Outlook 2013?

Question

I have an outlook plugin created using Visual Studio 2010 (.net 4.0 Client Profile) that works fine in Outlook 2007 and Outlook 2010. I just tested in 2013, and even installing addin seems to crash. After googling, I see several examples of problems that people face, but basically can not get a direct answer to this question:

Are there any prerequisites that would prevent the addition of VS 2010 Outlook to work only in 2013, or do I need to update Visual Studio and create a special version of my add in Outlook 2013?

Answer 1

Do you have Outlook 2013 on the computer where the add-in project is installed? If you do this, you can debug from VS 2010 by setting the "Launch external program" option on the "Debug" tab of the project properties window in Outlook 2013.exe. When I created my add-in, I was able to debug it using any version of Outlook that was on my development computer, and I don’t remember anything except the external path of the program.

If you use the installation project for installation, it needs another ComponentedId when creating launch conditions. To install in Outlook 2010 and 2013, you will need two different installation projects. The following are the PIA Office 2013 keys and Office 2010 keys .

Answer 2

The article Working solutions in different versions of Microsoft Office describes all the details. It states the following:

If you have developed solutions for Office 2010, you can run the same solutions in Microsoft Office 2013. Solutions created using Visual Studio 2013, Visual Studio 2012 or Visual Studio 2010 can run in Office 2013, Office 2010, or 2007 Microsoft Office.

What is the target .Net structure of your add-in? Have you tried to debug the code? Are there any exceptions?

Answer 3

Have you tried enabling the add-in again? It will not start after it is included in the turn-off queue. After you turn it back on from the screen with the add-ins disabled, you can check the COM-AddIn screen so that it loads, and then it should show you more detailed information, since you set the VSTO_SUPPRESSDISPLAYALERTS variable about what could happen in first of all. The problem may be that the add-in was hard disabled by Outlook. Please note that the add-in did not appear in the "Inactive Application Add-ons" section, and not in the "Disabled Applications" section. It matters: in the latter case, simply going to the COM-AddIn screen and checking the box is not enough to solve the problem.

Follow these steps for a hard disabled add-in?

• Open the Manage window, change COM add-ins to disabled add-ons, and then click Go. Select an add-on and click "Enable." Click "Close." OK, now the add-in can be loaded again:

• In the Manage box, change the add-ons over the COM add-ins, and then click Go. Check the box next to the disabled add-in. Click OK.

Link THIS website for more details.

Answer 4

I vaguely remember how I encountered AddIn crashes in the past ... resolution:

• Install Visual Studio 2010 Tools for the Office Runtime on the target machine .

2. Try to install VSTO AddIn again and you will not receive an alarm during installation.

Answer 5

Before you try to install it, you can try to run it so that the debugger gets more information about the real problem. As far as I remember, you just need to go to the properties of your project and change the running version of Outlook during debugging ...

You can follow this link for more information: http://www.greycastle.se/vsto-project-office-target-version/

Answer 6

Assembly loading problems are difficult to debug, since there are at least two levels when working with managed and source code.

• When the executable is launched, the native loader must find the file, load it into memory, along with all the dependent DLLs, in order to run it.
• The native loader scans the assembly manifest to determine this information, and then simply searches for all the DLL files and loads them into memory (in order).
• You can easily see this process using WINDBG and pointing to the EXE and running it from Windbg. The list of loadable modules is a native bootloader.
• If the dependency is an assembly of .NET managed code, then the native loader passes the download request directly to the managed loader known as "Fusion".
• You can easily configure the FusionLOG viewer to see what happens http://msdn.microsoft.com/en-us/library/vstudio/e74a18c4%28v=vs.100%29.aspx
• Download crashes at the managed level or within the managed level are easily detected either through WINDBG for Native or in Fusion Log View mode for managed code.

A few tips for loading a managed DLL: if the assembly contains a link to a DLL that is not included in this assembly, there is a strict "probe" order that follows to search for a dll. At least three attempts to find DLLs in different places, for example, in the assembly, in the root path of the program and in the GAC. If three attempts fail, the download stops at this point and the program does not start. When this happens, it is often seen as an environmental problem at the system level; however, this is actually a programming problem, because if the prerequisites are not completely known to the system administrator, they cannot guess about it. If you are a programmer who includes other dependent dlls, you should always consider whether to place them in an assembly to stop this problem. Otherwise, you, system administrators, and people using your program will have to wait until the root cause, which takes a lot of time, is determined.

You can say what I told the other department to use this DLL, and I have no idea what these other dependencies are! This is not an excuse, as there are great tools like ILDASM and even managed Walkers Dependency codes that will tell you everything you need. The best way to package these “other” DLLs is to simply include them in your assembly.