Issues getting a 2010 VSTO outlook plugin working on Outlook 2013?

Question

I have an outlook plugin built with Visual Studio 2010 (.net 4.0 Client Profile), that works fine in Outlook 2007 and Outlook 2010. I just tested on 2013 and even installing the addin seems to crash. After googling, I see a few examples of issues people have faced but fundamentally can't get a straight answer to this question:

Is there any prerequisite that would not allow a VS 2010 Outlook addin to just work on 2013 or do I need to upgrade Visual Studio and Create an Outlook 2013 specific version of my addin?

Sleight

Are all the versions of Office tested on of the same type (32-bit / 64-bit)? – Depalma

@Allen Elder - both versions are 32 bit – Sleight

1) Not sure if it will help during an install but did you try enabling the logging? Its point 7 here, 2) Whats the Event Log say? 3) Can you install with MSIExec logging msiexec /i "MyVSTOOutlookInstaller.msi" /l*v "log.log" - please update your question with this extra info. – Molokai

My suggestion is to work from the root cause of the crash backward. You mentioned "it crashed" but you don't say what the stack trace or logs of the crash are. If you post the stack trace and or other pertinent information you won't have to guess at the solution. NOTE: You can use WINDBG to see all of this by brining up SOS at the time of the failure. In the meantime, without that information, everything here is a guess. – Supremacist

@JohnPeters do you know how to use WinDbg to debug this, like how would you setup ADPLUS (or others) to capture the dump during install? I only know how to use it for High CPU, OOM, Hangs and Crash's. Does ADPlus work on install crashes, then how do you debug it (as you only get a slice at the time, no lead up info)?, you know what I mean? Obviously I've asked for the logs 4 days ago, seems OP isn't interested... – Molokai

ADPlus allows you to take a dump at the time of the failure. Now before you do that you may want to recompile the failing module and put the debug version into production (unless you have the PDB files for the one running there now). From there take the dump file open it up and bring up SOS. Once you are inside of SOS you are now looking at .NET stuff and will be familiar with the commands. Start with the stack trace of the thread that failed. – Supremacist

The other way to do this is to put Windbg on production machine open it up and attach to the failing process. Make sure to set the exception options so that it breaks and shows you "First Chance" exceptions. That way, Windbg get's the exception "Before" the application does. Learn how to start up the SOS add in. Keep in mind that when it breaks, it will break on the debug thread, bring up all the threads and change to the one that threw the exception not the one it broke on. – Supremacist

@Sleight I suggest investigating the crash. My experience with these plugins is that they usually crash because disposable objects aren't referenced properly, are then collected and your dependent objects don't have an unmanaged counterpart anymore. I remember ending up putting all objects I use in the class, and manually disposing them, to ensure things aren't disposed in the wrong order. If 2013 has a different memory access pattern, this can explain the crashes. PS: Easiest way to figure this out is to attach the VS debugger with 'start external program'. – Rosanarosane

@JohnPeters the thing is only MS have the private symbols which provides method bodies (not just method names as with the public symbols). Installing a VSTO addin wont actually run any of the code, the install simply adds registry keys and copies files and manifests. Hence taking a dump with Debug versions of the files wont make a difference. Sure a !Analyze on the dump could give you clues as to the module where the first/second chance exception occurred. Thats what I was asking, how can you WinDBG a crash of an installer without the private symbols, but delve into the dump is a valid point – Molokai

@JohnPeters I think I see what you're saying, now. Your suggesting to do a !CLRStack and follow the call stack to show the OP the smoking gun. You dont even care about the method bodies. btw I'm pretty sure msiexec is UNmanaged so SOS isnt going to help. But I do see now how you could get a rough idea of whats breaking during the install using WinDBG :) And you're right without the logs we're all guessing here!! – Molokai

Oh I didn't realize you are debugging and installer issue. Is this an Installshield install? If so 95% of installsheild runs native. In that case, you'll still need to take the dump and use !Analyze but make sure you are on right thread. From there its a dective game because chances are high you won't know the modules in the call stack. Don't give up hope because many of them have good names giving you a further clue. You don't want to get to disassembly mode just try to follow the call stack. And yes !CLRStack is what I use all the time for production managed issues with dumps. – Supremacist

One last note on the boot up sequence and Windbg... When a program starts, the native loader gets called immediately. As a request comes in from a dependency in an assembly for a .NET program it first reads the file and examines the assembly manifest. If it finds it to be a .NET program it immediately transfers a request to the .NET loader known as "Fusion". You can also get "Fusion" to write logs which will help you to find missing assemblies. You cannot count on any DLL or ASSEMBLY to have automatically included dependent DLLs. Fusion logs, along with ILDASM can tell you all. – Supremacist

Answer 1

Do you have Outlook 2013 on the machine you have the add-in project on? If you do, you can debug from VS 2010 by setting the "Start external program" in the Debug tab of the project properties window to the Outlook 2013 .exe. When I created my add-in I was able to debug it using whatever version of Outlook was on my development computer and I don't remember changing anything other than the external program path.

If you are using setup project for the installation it needs a different ComponenedId when you create its launch conditions. You'll need two different setup projects to install on Outlook 2010 and 2013. Here are the Office 2013 PIA keys and Office 2010 keys.

Marriageable

Answer 2

The Running Solutions in Different Versions of Microsoft Office article describes all details. It states the following:

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

What is the target .Net framework of your add-in? Did you try to debug the code? Do you get any exceptions?

Launcelot

You need to change the target framework to the full edition (not Client Profile). – Launcelot

Answer 3

Did you try enabling the add-in again? It won't run after its in the disabled queue. After you re-enable it from the disabled add-in screen, you can then check the box in the COM-AddIn screen to have it load which then should prompt you more detail since you set the VSTO_SUPPRESSDISPLAYALERTS variable about what may have happened in the first place. The problem can be that the add-in had been hard disabled by Outlook. Notice that the add-in did not show up under Inactive Application Add-Ins, but rather under Disabled Application Add-Ins. That makes a difference: In the latter case, just going to the COM-AddIn screen and ticking the check box is not enough to solve the problem.

Follow these steps for hard disabled add-in?

1. Goto the Manage box, change COM Add-ins to Disabled Add-ins, and then click Go. Select the add-in and click Enable. Click Close. OK, now the add-in can be loaded again:

2. In the Manage box, change Disabled Add-ins to COM Add-ins, and then click Go. select the check box next to the disabled add-in. Click OK.

Reference THIS site for further details.

Brassard

I detail all these steps and IMHO in much better detail here. I'm not sure you understand the question, the crash happens during an install not during the running of the AddIn. Only running it in Office could cause Office to disable it - not during installation. – Molokai

Answer 4

I vaguely remember encountering an AddIn crashing on installation in the past... resolution is:

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

2. Try the VSTO AddIn install again and you wont get the crash during installation.

Molokai

I'm assuming Office 2013 is on a different PC to one with 2010 because I've seen problems with users that had/have both installed on the same PC. – Molokai

Answer 5

Before trying to install it, you can try to run it trought the debugger to have more info on the real problem. As far as I remember, you just need to go to your project properties and change the launched version of outlook while debugging...

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

Sacrifice

Answer 6

Assembly Loading issues are difficult to debug because there are at least two layers to this when dealing with Managed and Native code.

1. When an executable is started the native loader must find the file, load it into memory along with all the dependent DLLs to make it run.
2. The native loader looks into the assembly manifest to determine this information and then simply hunts down all the DLLs and load them into memory (in order).
3. You can easily see this process using WINDBG and pointing to an EXE and running it from Windbg. The list of modules being loaded is the native loader at work.
4. If a dependency is a .NET managed code assembly then the native loader transfers the loading request directly to the managed loader, known as "Fusion".
5. You can easily set up the FusionLOG viewer to see what is happening http://msdn.microsoft.com/en-us/library/vstudio/e74a18c4%28v=vs.100%29.aspx
6. Failures of loading at either the managed layer or within the managed layer are easily spotted either through WINDBG for Native or the Fusion Log View for Managed code.

A few hints on Managed DLL loading: If an assembly holds a reference to a dll that is not included in that assembly, there is a strict order of "probing" which is followed to find the dll. There will be a minimum of three attempts to find the DLLs in different places such as in the assembly, in the program root path and in the GAC. If the three attempts fail, loading is stopped at that point and the program will not run. When this happens it is often considered a system level environmental issue; however, in reality it's a programming issue because unless pre-requisites are fully know by the system administrator there is no way they can guess at this stuff. If you are a programmer who is including other dependent dlls you should always consider whether or not to place them into the assembly to stop this problem. Otherwise you, the system admins, and folks using your program will have to wait until the root cause is determined which takes a long time.

You may say, well I was told by another department to use this dll and I have no idea what the other dependencies are! This is no excuse, as there are excellent tools such as ILDASM and even managed code Dependency walkers that will tell you everything that's needed. The best way to package these "other" dlls is to simply include them in your assembly.

Supremacist