I am coding an Outlook add-in using VSTO on Visual Studio 2019 (targeting Outlook 365). I want to do a test deployment install, rather than running it through Debug mode using Visual Studio. I figured that the "first step" for that would be to run the add-in using "Release" mode in Visual Studio. However, the add-in will not load in Outlook when I run it that way in Visual Studio.
When I first attempted this, a pop-up window appeared warning me that I am not running in Debug mode, and gave me a few options, such as "Stop Debugging" and something like "Run Just My Code" and 2-3 other options. I selected the first option "Stop Debugging", and Outlook started but did not load the add-in. Clicking into the Options on Outlook showed that it disabled the add-in because "it caused Outlook to crash." I have not been able to get that initial pop-up window to appear again, despite cleaning both the release and debug versions, and confirming those were removed from the project folders.
I can still run the add-in in Debug mode fine.
I found this answer from Eugene Astafiev regarding "hard" and "soft" disabling of add-ins by Outlook, and followed the instructions he linked-there -- but the add-in still refuses to load from Release mode. I also checked the various registry entries listed in the responses to this question and my add-in is actually listed under a "Never Disable" registry entry for Outlook.
Should I have selected a different option on that initial pop-up that appeared when I first tried to run the add-in in Release mode? And if so -- how do I get that pop-up to appear again?
Do I need to manually add entries to the registry when running in Release mode, to get Outlook to load the add-in? That seems counterintuitive given that Visual Studio automatically does that when running in Debug mode.
I still have not gone through the process of creating an installer per the MS instructions here, thinking that I need to get the add-in working in Release mode on Visual Studio first.
But is that actually the case? Can I create the installer using the Debug mode version? The MS installer instructions referenced above makes no mention of having to use the "Release" version, and this video (starting at 12:15) on deploying an Excel add-in using Visual Studio appears to just use the "Debug" version.
But by deploying from the Debug version, will it still be "optimized" for performance with the "debug symbols" removed, etc. as discussed in this video (starting at 5:06)?
And then that begs the final question -- should we even bother with "Release" mode on Visual Studio when coding an Outlook VSTO add-in?
I've searched and searched and have been unable to find any documentation discussing VSTO add-ins and "debug" mode versus "release" mode in Visual Studio, so any help or reference to such documentation would be greatly appreciated. Thanks in advance.
UPDATE: I tried creating a stand alone installer from Debug mode -- did not work. Creating the setup project in Visual Studio also killed my add-in from getting loaded by Outlook even in Debug mode. Got an "unhandled exception" popup in Outlook -- despite no exceptions coming up in Visual Studio. To be safe -- I had backed up the entire solution prior to trying any of this (learned that lesson the hard way about 10 years ago). Restored that -- at first it wouldn't load, but then remembered to clean the solution which did the trick.
UPDATE: Okay, making some progress. I had a "eureka" moment, when it dawned on me that starting Outlook by pressing "Start" in Visual Studio may be causing the problems under "Release" mode, since Visual Studio's debugger might still be trying to hook into the add-in while it is running. Instead -- I made sure to "clean" out the Debug version, switch to Release mode, and then I just built the solution without hitting Start.
At first the Add-In still wasn't loading, but this time because it "slowed down" Outlook, rather than crash it. I finally got it to load after I deleted the "Outlook\Resiliency\DisabledItems" keys from the registry as per this answer, and then launched Outlook directly rather than via the Start button in Visual Studio.
Now I'm going to try to create the Installer again, but this time using the Release version. I've been paying close attention to the files and registry keys that are created and deleted by Visual Studio for the "Debug" and "Release" versions, and think I have a better grasp on what the installer needs to do.
After several days and many hours of research and experimenting, I finally have my add-in installing, loading and running as-expected in Outlook on a test machine. To perhaps help anyone else struggling with these questions in the future, here is essentially a "brain dump" of what I learned:
The "Start" Button in "Debug" versus "Release" mode
As I mentioned in the second "Update" to my question, I had a "eureka" moment when I realized that running the add-in by hitting the "Start" button in Visual Studio is very different from doing so by launching Outlook directly outside of Visual Studio. As I discuss at the end of this post, I am fairly new to the Visual Studio IDE, and I had never seen this distinction discussed in documentation or forum postings.
Importantly, hitting the Start button inside of Visual Studio in "Release" mode triggers the following pop-up dialog window (at least initially -- see below):
As I discuss in my question, the first time I saw this, I clicked "Stop Debugging" and my add-in would not load in Outlook, in either Release or Debug mode. I was able to get this pop-up to reappear only after rolling back to a backup copy of my solution from before creating the Setup project. I discovered that accidentally by inadvertently clicking "Start" while in "Release" mode, rather than launching Outlook directly.
This time I clicked "Disable Just My Code and Continue" -- and my add-in loaded up fine inside of Outlook. Although I suspect that if I were trying to debug with breakpoints -- those likely would not have worked.
Also, the pop-up now still reappears when I hit Start in Release mode. I was never able to figure out why it permanently disappeared after I had hit "Stop Debugging" that first time. Maybe I had accidentally hit the last option with "(Don't Ask Again)" -- but I swear that I had hit the first option.
As for "Just My Code", here is a good SO question and answer discussing what that means.
"Optimized" Code and "Release Bugs" in Release Mode
Although I was able to get my add-in to load in Outlook in Release mode, it was exhibiting some strange behavior. After reading this SO question and several of the answers, especially this one, it dawned on me that this was being caused by one or more "release bugs" as a result of the optimization Visual Studio was doing to my code.
I decided that rather than spend countless hours trying to debug the IL ("intermediate language") code generated by Visual Studio -- I would instead see if I can just deploy the Debug version of the solution, which as I discuss below, I was able to do just fine.
Although there are clearly (and hotly debated) pros and cons to deploying a "Debug" version of an add-in (see the above SO link), such as maybe a performance/speed hit -- for me the choice was clear, given that the Debug version runs completely as expected without the weird behavior exhibited by the Release version.
The Registry and "Debug" versus "Release" mode
I also knew that for VSTO add-ins, in addition to writing/deleting files to "bin/Debug" and "bin/Release", Visual Studio also writes/deletes entries to the registry. When Outlook starts, that is where it checks to see if any add-ins should be loaded, as described by MS here.
However, I was not familiar with exactly how this works. I used the info provided by Microsoft at the link above to search the registry on my development machine to find the subkeys and values actually generated and deleted by Visual Studio each time I did a "build" and a "clean."
This was not as simple as looking in the "HKEY_LOCAL_MACHINE" and "HKEY_CURRENT_USER" sections (or "hives") of the registry. When I did that, my add-in was not under "SOFTWARE\Microsoft\Office\Outlook\Addins" in either hive. After doing a "find" for "Addins" -- and hitting F3 repeatedly -- after about 20 minutes or so I finally found it. (In hindsight -- I should have searched for the name of the add-in, oh well.)
For whatever reason, Visual Studio was instead saving the keys to my specific "HKEY_USERS" hive of my registry -- where there were 9 subdirectories based on various accounts I had setup on my development PC over the years. The hive for my currently active account was labeled with a long cryptic numeric string:
Finding this was crucial to my understanding, because then I could "build" and "clean" the solution in both Debug and Release mode, and see the changes Visual Studio was making to the registry each time.
Every VSTO add-in must have a subkey in the proper Outlook/Addins hive, and must have all four of the values shown in the image above ("Description", "FriendlyName", "LoadBehavior", and "Manifest").
The "Manifest" value is the one that tells Outlook where to find (somewhat confusingly) the "add-in.vsto" file (not the "add-in.manifest" file). It must begin with "file:///" and end with "|vstolocal".
Because my add-in uses a FormRegion, the FormRegions subkey was also important to track and learn how to use properly. The FormRegions subkey must contain a subkey for each type of Outlook item that your FormRegion is used for. In my case, it is only used for a MailItem, which in the registry is called (somewhat confusingly) "IPM.Note". The format for the value in that subkey is:
Name: [Add-in name].[FormRegionName]
Type: string (REG_SZ)
Data: =[Add-in Subkey name under Addins]
For example, if your add-in is named "TestOutlookAddin" with a FormRegion called "FormRegion1", and the main add-in subkey is named "TestCompany.TestOutlookAddin", then this subkey should look like this:
MS Setup Instructions Did Not Work for my add-in
I obtained all of the above info pretty much as a result of my frustration using the instructions provided by Microsoft for creating a VSTO add-in installer, with my add-in repeatedly failing to load on my test machine. It was failing whether I tried "Click Once" or the standalone Windows Installer method.
As for Click Once, after reading this Code Magazine article, I determined that that method was not appropriate for my add-in, especially because there are configuration settings the user can set, and a local SQLite database saved on the user's machine.
As for the stand alone installer method, when I couldn't get that to work with my add-in, I experimented with creating a very simple add-in with no third-party libraries -- and I was able to get the add-in installed and working using the above instructions from Microsoft. But I simply could not get my full add-in to load and run using that method.
I believe this is (partially) due to the fact that my add-in uses several third-party Nuget packages, and two class libraries that I coded myself.
On a whim -- assuming that it wouldn't work -- I tried simply copying the entire "bin/Release" folder to my test machine, and then manually created the appropriate keys in the registry (as I discussed above). It worked.
It worked, despite not having Visual Studio installed on that machine, the add-in loaded and ran when I started Outlook. However, the add-in was exhibiting the strange "release bug" behavior I discussed above.
So I tried again, this time copying over the "bin/Debug" folder instead. It worked.
It loaded and ran on my test machine exactly as it did on my development machine.
So I learned (the hard way) -- that deploying a VSTO add-in (or at least MY add-in) requires essentially two steps:
Copy all of the files from either bin/Debug or bin/Release to the target machine.
Create the appropriate keys and values in the registry pointing Outlook to where those files are located.
And oh... I should add to that a "Step Zero":
Check for and install the .Net Framework and VSTO Runtime
Manual Copying versus Windows Installer -- Likely Security/Trust Problem
With the above in mind, I went back and created a Setup project in Visual Studio that simply copied all of the files from bin/Debug to the target machine and sets up the registry keys.
I did the install, but on launching Outlook, my add-in initially loads, and then mysteriously unloads silently.
I believe -- although have not 100% confirmed -- this is due to the way the security/trust settings are handled by Outlook when the add-in is "manually" copied to the machine versus being installed via a Windows Installer.
With the Windows Installer, I get the standard "UAC" type of warning message:
However, "manually" copying the files to the test machine and manually setting the registry keys, triggers instead the following "Microsoft Office Customization Installer" message upon starting Outlook:
Clicking the "Install" button results in the add-in loading and running properly.
I believe what is happening -- although it is a guess really -- is that the Windows Installer is not properly designating the security/trust settings on all of the .dll files used by my add-in, causing Outlook to disable it silently after starting to load it. There may be a way to configure the Setup project in Visual Studio to fix this -- short of going through the whole process of making the entire solution "trusted" with a certificate, etc. However, I have been unable to find any documentation on that.
Regardless, "manually" copying over the files and setting the registry keys triggers the "Microsoft Office Customization Installer" message, which then seems to properly configure all the trust settings to allow the add-in to install and load. Also -- that message appears only the first time Outlook is started with a new "manually installed" add-in.
Inno Setup To the Rescue
I did some more research and found the excellent free and open-source Inno Setup installer builder for Windows. This allowed me to create my own Installer that simply compresses the files in my bin/Debug folder into a single .exe file. Running that .exe on the target machine simply copies the files to the designated location on the target machine, and then writes the needed keys and values to the registry. Launching Outlook then brings up the above MS Office "Customization Installer" message, and clicking "Install" loads and runs the add-in which then runs perfectly fine.
What's great about this is that it is free, and provides the same "Installer" and "Uninstaller" type of functionality as the VS Setup project is supposed to. And there are scripts people have developed and shared for checking whether .Net is installed, etc.
Most importantly, it just works.
Final Note
Although all this was difficult to figure out on my own, it forced me to learn a great deal about the differences between "Debug" and "Release" builds in Visual Studio and VSTO, and for that I am grateful. I recently returned to coding after a 12 year hiatus, and this is my first attempt at an Outlook VSTO com add-in; and I had had only cursory prior experience with the Visual Studio IDE.
The Stack Overflow community and knowledge base has been a tremendous help to me, and I hope this Answer is a worthy addition to that. Although Microsoft appears to be moving away from VSTO com add-ins in favor of web-based add-ins -- there is still a place for com add-ins, particularly for accessing the user's local storage, which web-based add-ins cannot do (as far as I can tell). So -- although perhaps unlikely -- maybe this Answer will help someone in the future who is also struggling with "Debug" versus "Release" mode and how to deploy their VSTO com add-in.
I'm quite new to VS Code. I have been debugging DLLs for 3rd party applications earlier in Visual Studio but it seems all the tools available there are not available in VS Code.
What I have been doing in VS earlier is:
create, develop and build my DLL to the plugins folder of that 3rd application (with references to the 3rd party application's libraries)
add the 3rd party exe as another project and set it as startup project.
when starting debugging session, VS automatically launches/attaches to my dll, i.e. I can step through my code when I start the plugin inside the app.
I am able to successfully build the DLL in VS Code to the correct folder and it works (will show me the simple msgbox i am waiting for). However, when I try to debug it by attaching the debugger to the 3rd party app process, the debugger does not stop at the breakpoints. When I hover over the breakpoint during debugging (which is not red anymore during debug), I get the message "No symbols loaded for this document". I guess I'm doing something wrong. The .pdb for the DLL is in that plugins directory. Is this because the debugger does not find it? Honestly, I'm not very well in with the launch.json contents yet (no need to work with those in full VS). What is the best way (if any) to do this kind of debugging in VS Code? In case this is something that definitely can't be done in VS Code, please let me know, so I know I need to return back to full IDE.
It turned out I just had some issues in my launch.json. I am now able to step through my code and the UX is practically the same than that with full VS. Problem solved.
#vernou Thanks for the link anyway!
I developed several Word add-ins with visual studio.
After working for over 2 years without any problems my dev machine is unable to load an add-in in Word (or Excel for that matter) and run Word (or Excel).
After several things I've tried, see below for details I'm still stuck in the same place. Word just directly stops causing VS to detach the debugger because VS obviously sees the process exit.
Some things to know:
The event viewer does not show any errors
I already added VSTO_SUPPRESSDISPLAYALERTS with value 0 to the environment variables
Word nor VS shows me a message what went wrong
I already added VSTO_LOGALERTS with value 1 to the environment variables
There is no logfile to be found somewhere in the documented places
Loading Word directly loads the Add-in without any problem.
If I attach the VS debugger to the Word process I'm able to set breakpoints and do normal debugging in the Add-in
What I've tried so far:
Added the above mentioned environment variables to both user specific and system wide lists.
Reboot my machine to make sure the environment variables where loaded properly
Checked with RegEdit if the Add-In was correctly added to registry with a LoadBehaviour value of 3
Repaired Microsoft Office Developer Tools for Visual Studio 2013 (Update August)
Uninstalled and reinstalled Microsoft Office Developer Tools for Visual Studio 2013 (Update August) (reboot in between)
Made a complete new and empty Word Add-in to make sure there is nothing wrong => exact same problem
Made a complete new and empty Excel Add-in => same problem with Excel.
Used ProcMon to see if something is missing, but this shows too much information to clearly see what is happening. I do see there is no logfile being created.
So I'm completely in the dark why this is happening. It worked for at least 2 years on this machine. I can't find anyone with a similar problem on the net.
Hopefully somebody has a clue!
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?
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?
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.
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?
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:
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.
I vaguely remember encountering an AddIn crashing on installation in the past... resolution is:
Install Visual Studio 2010 Tools for Office Runtime on the target machine.
Try the VSTO AddIn install again and you wont get the crash during installation.
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/
Assembly Loading issues are difficult to debug because there are at least two layers to this when dealing with Managed and Native code.
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.
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).
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.
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".
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
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.
Python -> c++ dll -> c# dll
I have a com interop c# dll that is loaded in a wrapper c++ dll throught the .tlb file generated in c# to be used in a python project. When I run in my computer it works fine but when I run in a computer that just got formated it gives:
WindowsError: exception code 0xe0434f4d
I have the redistribute c++ installed and the .net compact framework 3.5 on the formatted computer.
How can I see what is the correct exception on a computer that does not have visual studio installed? How can I debug all of this? I can't debug the dll's itself can I?
Note: in my computer all works well so maybe is some dll or file missing. I allready used Dependency Walker to see if there's some dll missing, and nop!
Download the Microsoft Debugging Tools for Windows.
It contains the WinDbg debugger, which can also be used for debugging.
Advantage of WinDbg over Visual Studio is that you have much more low-level commands to find problems.
Disadvantage of WinDbg is that it's not that user friendly (compared to Visual Studio).
You can use WinDbg or other good applications to attach to the process or even run the application in the debugger application.
Another really good software is OllyDbg.
Both of these will both allow you to set breakpoints on different locations in your application.