We Keep Coding

Outlook add-in will not load in Release mode on Visual Studio -- and is that needed for deployment of the add-in?

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.

Could not find type...Platform issues in Visual Studio

I just jumped back into a project that previously had no issues. We just upgraded to visual studio 2012. This morning I open my project to work on my code. I am getting designer issues all over the place.
"If this type is a part of your development project, make sure that the project has been successfully built using settings for your current platform or Any CPU"
It all seems to be coming from this platform issue. I have had zero issues in the past. I cannot find any information on how to fix this. I even go to open the designer on a file that previously worked (pre VS2012 install) and that fails.
So I went back to VS2010...without changing anything and attempted to open the same designer on the same file that previously worked and I also get an app crash.
Did somehow my visual studio 2012 install cause all of this?

Make sure that you are choosing the right CPU architecture for your designer. If it is ARM then you might see that message. You can check your CPU settings for your project like this:

Visual Studio 2012 csc.exe Error. Executable not valid for OS

I am getting the following error when trying to compile and test any type of project in Visual Studio 2012 Professional.
Error 1 The specified task executable "Csc.exe" could not be run. The
specified executable is not a valid application for this OS platform.
After testing multiple suggestions online nothing has fixed the problem. Anyone know what is causing this? Is there a new version of Csc.exe I need to get a hold of? I know this is the compiler just not sure what I need to do to fix the problem.

I had this exact problem today on my Win7 Machine. As Hans suggests, 'Navigate to C:\Windows\Microsoft.NET\Framework\v4.0.30319 and type "csc".'
The file may still exist but if you can open it with notepad, it will probably show just plain text of some errors. This is the indication that your compiler has been destroyed. At my office we have come up with a theory that a Windows update may be causing this because only a few machines have been affected, but I haven't read much online about it until now.
We fixed this by copying someone else's csc.exe into the C:\Windows\Microsoft.NET\Framework\v4.0.30319 directory and recompiling. Be sure to set the options on the file to read-only so this won't happen again. Good Luck!

The problems associated with csc.exe in Visual Studio 2012 can mostly be solved by repairing Visual Studio.
You need to repair Visual Studio. Go to Control Panel -> Programs. Then select your version of Visual Studio you are using and press "Change"(or right click it and press "Change"). When the setup appears, click "Repair".

I am on Visual Studio 2017 but this is the first google result that pops up for "csc.exe not found"
When I got this error I had to restart Visual Studio, being sure to select 'Run As Administrator'. Everything worked after that

I've faced this problem while i am trying to move Asp.Net Mvc Project from one computer to another ; error message was : The specified task executable location "c:\users\mypcname\documents\visual studio 2015\Projects\TestMVC\packages\Microsoft.Net.Compilers.1.0.0\build\..\tools\csc.exe" is invalid.
I solved this by
Creating new Mvc Project ;
going to that folder \Microsoft.Net.Compilers.1.0.0\build..\tools
and Copied the csc.exe file to my Projets >> \Microsoft.Net.Compilers.1.0.0\build..\tools\
i think when i was copying the project from the original Computer i left that csc.exe file in the specified folder.
Hope this will help someone.

Check your solution properties (right-click on Solution and select 'Properties') and make sure that the 'platform' field (Configuration Properties) is set correctly.

I think this problem is caused due to improper PC clean up. I was running Quick Heal PCTuner 3.0 software on a 64-bit windows 7 machine but suddenly due to loss of power my machine was shut down then when i opened it again I was getting this problem in VS 2013. Even TortoiseSVN checkout was not working and throwing internal error and something like corrupted disk also was shown when trying to delete some files on the harddisk.
I ran the PC Tuner again doing the Disk, Registry and traces clean up and it got fixed. maybe this problem may occur due to other cases also but is mostly related to the system's files In my case this is the fix
Regards.

in my case helped (I had .net framework 4.5.1 and vs c# 2010 express):
download the newest .net framework and run repair

On Visual Studio 2013, the same problem solved by doing this for me:
Right click the solution and open Configuration Manager. For the project(you may see at least one there), I've changed the Platform from Any CPU to x86 for the project that may causing the problem.

I've tried to delete and move csc.exe file but it doesn't do anything.
Then simply I upgrade .net version and than downgrade (returned to its original state) and it works.

I solved my problem by copying the whole folder containing my visual studio solution
From C:\Users\me\Google Drive...
To: C:\Users\me\OneDrive...

WPF DotNET Application will run in debug mode, but .EXE will not run

I wrote a WPF application in C# using VS 2010. The application will run fine in debug mode using Visual Studio, but when I go to run the .EXE from the bin\release folder, nothing happens. I do not get any error messages from windows and there are no errors or warnings in VS. I have tried to build, rebuild and clean the solution (in every possible order) with no luck. My solution contains 2 projects, both of which use .NET 4.0 framework, and I have .NET 4.0 installed on my PC. I have tried on both XP and Win7 and still nothing.
I also just noticed that the output from Debug when I run the application in debug mode says: "Cannot find or open the PDB file" after each .Dll it loads.
I am compiling to the Release folder every time, but i did try changing it to the debug folder and clean/rebuild just to see if that would make a difference, and it didnt, so I changed it back, tried it again, and still nothing.
Any Ideas?

Here are a couple of ideas that come to mind
If you are on a x64 machine, try changing the application from being AnyCPU to x86. This the mode that applications default to in debug mode and it's possible an issue running in x64 is causing a problem in release builds
Possible the Release binaries are out of date. Delete the binaries from the Release folder, rebuild and run the newly generated runs
Run the release build under the debugger in Visual Studio and see if it till crashes

I was experiencing the above issue too, however none of the other solutions worked for me.
My Application logs in Event Viewer listed event ids 1018 and 1022. This appeared to be bizarrely related to an ASP.NET 2.0 dll (bizarre; as this was a blank WPF project only). The logs contained messages like this:
Windows cannot open the 64-bit extensible counter DLL
ASP.NET_64_2.0.50727 in a 32-bit environment
In the end it turned out to be resolved when I disabled my anti-virus. I had read that this resolution worked for someone with McAfee; and it also worked for my environment, which has Avast.

I assume you tried on a machine that doesn't have visual studio installed, and also none of the components you are using for development.
You have only one option: start the application with a debugger on the machine that causes problems and check for exceptions there. (use WinDBG for example - it's light and easy).
This looks like a problem with missing dependencies, but might be something else also.
The Debugging Labs should give you enough information on how to use windbg to find your problem:
.NET Debugging labs
Also use this:
WinDBG Cheat Sheet

(JaredPar) answer looks right (x64), but if not try right clicking on the EXE and running in admin mode for win 7.

I had a very similar issue.
Check out this setting on your App Pool entry:
Go to Advanced Settings.
Change 'Enable 32-bit Applications' to 'TRUE'.
This worked for me!

I'm going to go with a wild guess that:
Either you have some odd corruption in your .NET Framework installation
There is some debug/release-specific code using #if DEBUG or the such that is substantially different to cause issues.
You have not compiled recently into Release yet (Try changing it to Release before compiling your latest code and make sure you get no errors).
Those are the only things I can think of off the top of my head.

I had run into a similar issue, I was missing a custom folder in the release mode I was referencing in the constructor. Adding the folder to the release fixed the problem.

When I run a unit test visual studio crashed

When I am working with a VS 2008 Team System solution with a very large number of projects VS crashes on me all the time.
Strange thing is that the other developers don't have the same problem and it has only been a problem for me the last couple of days. Don't know suddelny why i'm having this problem.
When i run a unit test it crashes and when i get rid of a bunch of projest from the solution and run the same unit test it's doesn't crash.
It has nothing to do with add ins, VS settings, the machine spec and i already tried reinstalled VS. It has something to do with VS running out of memory or something
Here are the steps i took so fare:
Reinstalled VS then rebuilt the solution, deleted all VS files like the .user file and deleted all add ins.
I also increaed my virtual memory. My machine isn't running at 100% CPU or 100% RAM at the time and there is no usful messages in the event log.
It crashes when i do anything really except opening and closing files, like running a unit test or going into debug mode
any suggestions?

Your question doesn't have a lot of info - no error messages, no steps you take to get the crash, no steps you've taken to troubleshoot or what the outcome was, not even what you mean by "very large number of projects"...
So when you say "it has nothing to do with add ins, VS settings.." it's hard to accept that on faith, (or even help you at all honestly).
First thing I would do would be to reset all settings with Tools | Import and Export settings..., then "Reset all settings". I would make sure all extensions are uninstalled (not just disabled. And I would delete my .suo file (been burned by that before).
If none of that works, a repair install or uninstall/reinstall would be next. I'd also look at any new applications or service packs I've installed over the last few days.

When using VS 2008 with ReSharper (5.1, 6.0 or 6.1) I had the same problem. After uninstalling a seperate NUnit installation the crashes disappeared for me.