Develop Reference

Cannot add reference to Outlook 2016 (Office 365) Interop (16.0.0.0)

I'm trying to add a reference to 'Microsoft Outlook 16.0 Object Library' in a C# .NET 4.6.1 WPF project, because I have office 2016 installed. Previous versions of the Object Library are incompatible with the 2016 version of office.
If I use Excel's VBA editor, 'Microsoft Outlook 16.0 Object Library' is listed, and exists in C:\Program Files\WindowsApps\Microsoft.Office.Desktop_16010.9126.2116.0_x86_8wekyb3d8bbwe\VFS\ProgramFilesCommonX86\Microsoft Shared\OFFICE16\MSOUTL.OLB, as you can see below:
However, when I use Visual Studio, the COM tab does not list 'Microsoft Office 16.0 Object Library', and when I try to browse to C:\Program Files\WindowsApps, i get 'You dont currently have permission to access this folder', and clicking 'Continue' (to get access) results in 'You have been denied permission to access this folder'.
So basically, the Office 2016 dlls seem to have been tucked away in a folder that is inaccessible to man, dog, and local administrator.
All I'm trying to do is connect to the open Outlook application, and then send an email with an attachment, so perhaps another question to ask is, is there some new fangled way to communicate with Outlook 2016 that hasn't cropped up in my Googleathon?
Also worth noting is that my version of office is installed as a 'Windows Store Application' and therefore does not appear on the usual Add/Remove programs list, so I can't find any 'repair' options for the installation.
Thanks.
Further investigation reveals that I am doing the right thing - trying to add a COM reference to 'Microsoft Outlook 16.0 Object Library' is now the correct way to target Outlook ... https://stackoverflow.com/a/21018418/5040941.
I've checked the GAC, and the assemblies aren't registered. I've done a repair via the 'Apps and Features' right-click start menu option, and they still aren't appearing - it's as if the Windows Store apps just shove their dlls into the Program Files\WindowsApps\* folder, and don't bother to register them in the GAC.
In answer to the much appreciated comments!
Using the following code
Outlook.Application application = (Outlook.Application)Marshal.GetActiveObject("Outlook.Application");
If I use the nuget Microsoft.Office.Interop.Outlook package, i get a System.Runtime.InteropServices.COMException: 'Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))' exception.
If I try using Microsoft Outlook 15.0 Object Library or Microsoft Outlook 14.0 Object Library references via the Assemblies/Extensions tab of Add Reference, I get a System.Runtime.InteropServices.COMException: 'Invalid class string (Exception from HRESULT: 0x800401F3 (CO_E_CLASSSTRING))' exception.
I don't think accessing the WindowsApps folder is the way to go.
Firstly, it's locked down for some reason which typically indicates the potential for trouble if i start digging around and changing security permissions, not to mention the fact that maintaining a copy of the latest dll in my solution will undoubtedly add unnecessary complexity to my project.
Secondly, but more importantly, if I have office installed, and I can access 'Microsoft Outlook 16.0 Object Library' from Excel Vba, then why can't I access it from Visual Studio?
There is obviously some issue with the installation not registering the dlls properly, only Excel has some trick it uses to make the reference available anyway.
Has anyone reading this managed to install Office 365/2016 Windows Store and found a reference to 'Microsoft Outlook 16.0 Object Library' in Visual Studio?
Am I the only with this problem?! Because it affects multiple computers in my office running Windows 10 and Office 365 ...
In answer to RogerN (thanks), please see the image below - I don't have Microsoft.Office.Interop.Outlook version 16 listed, and Microsoft.Office.Core isn't listed either.
If I try to use the v15 library, I get the following error:
System.Runtime.InteropServices.COMException
HResult=0x80040154
Message=Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
Source=mscorlib
*AND THE ANSWER IS *
The two computers I bought from Dell are 64 bit, but they come preinstalled with 32 bit, windows store versions of MS Office 2016/365.
In order to fix the problem, I had to:
uninstall the store app from Settings > Apps > Apps&Features > Microsoft Office Desktop Apps > Uninstall
log into portal.office.com
select install office apps, advanced, choosing the 64-bit version
Quite why Dell think we want 32 bit versions installed on 64 bit machines, or why someone from Microsoft hasn't posted a solution to this problem, is beyond my understanding, but nevertheless, RogerN was correct. Thanks to everyone for taking time out their days to help me out.

Elaborating on my earlier comment: From what you've described, it sounds like you've installed a 32-bit version of Microsoft Office on a 64-bit machine. Only 32-bit COM objects would have been registered, and therefore a 64-bit .NET application would be unable to find them. If you search your registry, you ought to find that the 0006F03A-0000-0000-C000-000000000046 class ID is only registered under the Wow6432Node.
To resolve the issue, you could either install the 64-bit version of Office or force your .NET application to target the x86 platform.

How can i add Microsoft.Office.Interop.Word to setup file?

I'm creating a WPF application in Visual Studio 2015 that uses Microsoft.Office.Interop.Word for create Word document.When I create setup file for my project and run it in my PC everything is good but when I install and run it on a different PC it doesn't work.
How can i add Microsoft.Office.Interop.Word to setup file?

This interop is registered in the GAC after office / msword install on the PC. (which means you don't need to distribute the dll)
Check here for more info about PIAs. It states the following:
To perform certain development tasks, the PIAs must be installed and
registered in the global assembly cache on the development computer.
Typically, the PIAs are installed automatically when you install
Office on the development computer. For more information, see
Configuring a Computer to Develop Office Solutions.
The Office PIAs are not required on end-user computers to run Office
solutions. For more information, see Designing and Creating Office
Solutions.
Best option is to use some alternative of MsWord (check comments) or you can check on startup in the registry for the office install if available and if not you need to notify the user which functionalities won't work (or disallow usage of the application if more appropriate).

You don't need to explicitly include PIA as part of your set up (from C#4 onward)
In your local - right click assembly properties and make Embed Interop Type to true. Relevant types required to communicate to office com type will get embedded to your assembly.

VSTO application add-in won't load - says "The Managed Add-in Loader failed to initialize"

I have a PowerPoint 2010 application-level add-in developed using VS2012 and VSTO. It works with PowerPoint 2007 too. I built an installer for it using the (terrible) InstallShield LE crippleware provided with VS2012. I've been able to install it on various test machines, but now that I'm trying to deploy it to a client, they can't install it on some machines.
One user at the client's site can install it, but that user works in IT and has admin rights on his machine. However, when the IT admins try to install it on a "normal" user's machine, the install seems to go OK but the add-in is not loaded by PowerPoint.
The "COM add-ins" dialog shows the message:
Load behavior: Not loaded. The Managed Add-in Loader failed to initialize.
[In case it's relevant, this client uses Office 2007. Note however that it works OK on Office 2007 both on my test hardware and for that one user at the client.]
Is there anything I can do to figure out why? Is there anything obvious that I should be doing as part of the installation? Clearly the registry entries are being set, because the add-in is listed in the COM Add-ins dialog. And I assume that all the required files are installed, because the installer works fine on other machines.
I guess it may be a security-related issue. I should note that I'm not doing anything security-wise, and I don't think the InstallShield thing is doing anything helpful in this regard. I don't know whether it's necessary to digitally sign my code (I haven't), or somehow set some security policy stuff (I wouldn't know how). I've seen some stuff on-line about using CasPol (?) to apply security settings to add-ins, but that applied to older versions of VS and/or ClickOnce, and I wasn't sure whether I needed any of that.

It turns out that the VSTO runtime is not installed with Office 2007 (it is installed with Office 2010). The IT user who could load the add-in already had it because he'd installed something else that included it (I guess). The other users did not have it.
So, I updated my installer to include it, and it now works.

Detect Outlook installed and load dynamically INterop.Outlook

I have a Windows Forms application in VS2010. It has a reference to Interop.Outlook (2003). Then, I have reinstalled Windows XP and VS2010, but not install Outlook.
Now, the project not compiles.
I think this, my application will not work if Outlook not installed in machine that my program executes on.
I need to know if I detect Outlook installed, and load dynamically Interop.Outlook.dll (for using the Outlook PIA or Embedded Interop types in .NET 4).
If the machine has Outlook (2003, 2007, 2010, perhaps need code to detect version and do compatibility of Outlook versions) installed, the application works fine with functionally Outlook.
If the machine hasn't Outlook installed, the application works fine without functionally Outlook.
Any sample source code or goog patterns and practices about it??

To detect if Outlook is installed, look for the "Outlook.Application" ProgID.
From an installer, look in the registry for HKEY_CLASSES_ROOT\Outlook.Application
At runtime, you can do this:
using System;
using Microsoft.Office.Interop.Outlook;
class Program
{
static void Main(string[] args)
{
var outlookType = Type.GetTypeFromProgID("Outlook.Application");
if (outlookType == null)
{
Console.WriteLine("Not installed.");
}
else
{
var app = Activator.CreateInstance(outlookType) as Application;
Console.WriteLine(app.Name);
}
}
}
To avoid the problem of dynamically loading the interop, you should set Embed Interop Types to true for Microsoft.Office.Interop.Outlook.Interop.dll

check the Installer APIs to detect the install state of Outlook or use one of the method described here.

FileLoadException on windows 2003 for managed c++ dll

My company has login integration with GroupWise, and Exchange 5.5/2000+. The Exchange 5.5/GroupWise logic is done using wldap32.dll (win32), and so the login code is in a managed c++ class. When the configuration tool (or the backend service) tries to load the dll built off this managed c++ project on my XP development box, it works fine. On QA/Customer Windows 2003 boxes, a FileLoadException is thrown.
First off, this used to work fine. Secondly, I've validated the same working code on my box fails on the qa box.
How can I track down the cause of this exception?

Have you changed your development environment recently? In particular have you installed a service pack or new release of Visual Studio?
It appears you are linking against a C++ runtime that is not available on the client's server. You can use the Windows Event Viewer to identify the DLL failing to load, or if this shows nothing, use depends.exe to see what runtime DLLs are dependencies for your managed code.
Microsoft has moved to using side-by-side installation to handle "DLL hell", basically this allows multiple versions of a DLL to be installed (side-by-side) concurrently on a Windows installations and have applications load the correct version of the DLL at run-time. Recent releases of Visual Studio make use of this technology so I suspect this is the cause of your 'sudden' incompatibility.

Not to answer my own question, but support just updated the bug with the text following this paragraph. I'm still interested in thoughts on tracking down situations like this.
Resolved by downloading and installing the Visual C++ 2008 Redistributable
Package for Windows on the IMS:
http://www.microsoft.com/downloads/details.aspx?FamilyID=a5c84275-3b97-4ab7-a40d-3802b2af5fc2&DisplayLang=en