We Keep Coding

c# - Office 2016 interop dlls [duplicate]

I had to import an older project (in .Net 2) into Visual Studio 2013, it makes use of the Microsoft Primary Interop Assemblies.
Visual Studio said that I need to add references to the project. Now I went and did some reading and apparently Microsoft has only released the PIA for office 2010? (I have Office 2013)
Now what I would like to know is.
Can I get it to work with office 2013 and be backward compatible?
And if so is this a good route to go for the future? Is it going to be compatible? Because I see you need .Net 2 (at the latest) and Windows 8 comes with 4.5 and not 3 (by default) and most new computers are going to have Office 2012 or 2013.

PIAs are a historical artifact, required only by old .NET versions (before v4). They have been thoroughly and elegantly replaced by the "Embed Interop Types" feature, also known as the "No PIA" feature. Supported since Visual Studio 2010, you'll find it back in the Properties window when you select a reference assembly. It defaults to True. A good video that covers the underlying technology is available here.
Which is the reason that Microsoft doesn't publish the PIAs for Office 2013, they expect you to embed the interop types instead.
The feature is very desirable, it avoids your customer having to install the PIAs on his machine and for you to include them with your installer. Solving the issue when neither takes care of it, an entirely too common mishap. In addition, the PIAs for Office are very large, the great advantage of embedding the interop types is that your assembly only contain the types that you actually use. Many megabytes reduced to a few kilobytes.
The workflow is a little different. Instead of adding a reference to the Microsoft.Office.Interop assemblies as available in the Add Reference dialog, .NET Framework tab, you now use the COM tab. And pick, say, "Microsoft Excel 15.0 Object Library" to generate the interop types for a program that uses Excel. If you load an old project that previously used PIAs then just remove those reference assemblies and add them back from the COM tab.
Do note that a feature is lost, intentionally targeting an old version of Office that you don't actually have installed on your dev machine is more difficult. If that's a requirement then you still need the PIAs for that version, force the Embed Interop Types to True in the Properties window. Actually doing this is questionable, Microsoft has a hard time keeping new Office versions completely compatible with old versions. They've kept it up for 15 years now but it has been running out of steam. A worst-case scenario is targeting a newer version than you have installed on your machine, that's liable to make your program crash with very hard to diagnose exceptions like AccessViolationException.
Do note that you have to make small modifications to your code to allow it to work. The synthetic "XxxxClass" classes are not embedded, just the "Xxxx" interfaces. Simply remove the word "Class" from the new statement.

VS 2015 Community with Office 365 - for whatever reason the Add from the COM object does not work. The solution is go into the GAC and find the interop assemblies, copy them to a temp directory, then add to your project like any DLL.

Also, if you don't know by now, Windows 8 does have older versions of .NET Framework but they aren't installed by default. Go to Program Features ---> Add features to Windows ----> and the first check box should be .NET 3.0 and maybe 2.0. Note, if you are on a WSUS server you will need to tell Windows to grab the files from the Windows Update servers. Hope it helps!

Officially there is no backward compatibility of the PIA for Office. In fact it works.
For backward compatibility reasons I'm using the PIA for Office XP since several years and it works fine with Office XP, 2003, 2007 and 2010 (not yet tested with 2013) and on Windows XP, Vista, 7 and 8.
For compatibility with the different versions of Windows I'm using the .NET framework 3.5.
For the future... it depends of what you are doing with the PIA. If possible it is far better to directly deal with the Open XML files or to create an add-in for word/excel.

I just found out that the Visual Studio 2013 express does not have office-support anymore. So you need at least the pro-version to make it work.

Differences between Office Interop libraries

I am working on a C# .NET v4.0 application which includes generation of Word documents. The application uses the version 14.0.0.0 of the Microsoft Office Interop Word library.
My computer is running Office 2010 (Office14) and I am wondering what are the differences between the versions 14.0.0.0 and the 15.0.0.0 for the library?
Is there any obligation to use one or the other of these two libraries depending on which version of Office I am running?

If you link your app to the version 14.0.0.0 (Word 2010), it will work with Word 2013 (version 15) if you use the "Embed Interop Types" feature in Visual Studio.
If you link to 15.0.0.0, it will not work with Word 2010.
Linking to 15.0.0.0 will let you access to new functionality of 2013 if any.

If you don't need any automation of the application (Word) itself then I would recommand to use the offical Open XML SDK 2.5 for Microsoft Office to process any xlsx docx or pptx.
Download Open XML SDK
Update
I think it does not matter which version. More important is that your implementation works with the version that the customer has currently installed! Maybe or maybe not there could be some breaking changes between the interop interfaces between major versions.

Office 2003 and extensibility.dll deployment blues

I have been trying to create a deployment for a C# Outlook 2003 add-in. It requires only NET 2.0 and relies on IDTExtensibility2 (of Extensibility.dll). Upon making sure Office 2003 PIA are installed the add-in still won't register because of Could not load file or assembly 'Extensibility, Version=7.0.3300.0, Culture=nuetral, PublicKeyToken=b03f57f11d50a3a' or one
of its dependencies. Strong name validation failed. (Exception from HRESULT:
0x8013141A)
I don't think deploying Extensiblity.dll is legal and I could not make it work even if it was. So how to make sure it is available on the target PC?
I could not find an adequate solution anywhere.
The solution is developed in VS 2010.

If your outlook add-in is signed using a strong name key then any external libs that you reference will also need to be strong name signed.
I've had a similar problem to yours in the past where 3rd party libraries were not signed with a strong name.

After doing a bit of searching around I came across this Microsoft Support article that provides a resolution.
In brief:
When you use Microsoft Visual Studio 2005 to create add-ins, smart
documents, or smart tags, you may experience the following symptoms:
The add-ins, the smart documents, or the smart tags cannot be loaded in any Microsoft Office application.
The add-ins, the smart documents, or the smart tags do not run in any version of Microsoft Office.
and their resolution:
To resolve this problem for Visual Studio 2005 developers, a
redistributable version of the update for Visual Studio 2005 is
available.

Found Extensibility.dll in
\Visual Studio Tools for Office\PIA\Common
folder. Copied it to the project folder.
I have VSTO 2010. Added the reference to my project, and the compile error went away. Same version on the error: 7.0.3300.0. VSTO is distributed freely by Microsoft for developers, to create solutions for Microsoft Office, but the license document enclosed with VSTO 2010 doesn't allow you to make copies of it except for your own use. That being said, I would pester Microsoft about the dll, as obviously you need it for your project. Obviously, they should have added a clause to the license to allow distribution of the dll by developers.

VSTO Excel Add-In with Visual Studio Express

I want to create an add-in (a ribbon precisely) for MS Excel by using Visual Studio C# 2010 Express. I have searched and read about it here and here and somewhere else. However, when I want to create a new project I don't see any template as described, I don't see even the Office tab. Is it because I am using the Express edition? I think it shouldn't be. Because in this official comparison they say all editions are capable of office development.
What can I do to develop this add-in?

According to this post on the MSDN forum, Visual Studio Tools for Office are not available in the Express edition. I'm not sure where you're reading that on the comparison page (a quick glance said nothing about the Express edition).

A good alternative to VSTO for making an Excel add-in with .NET is Excel-DNA (which I develop). It is a free library that integrates your .NET assembly with Excel using the C API (as an .xll add-in). You can create user-defined worksheet functions (UDFs) for Excel (which are not supported by VSTO), and make ribbons, RTD servers. And you get easy deployment (a single .xll file) without needing any registration or admin rights, even for ribbons and RTD servers.
Another option, if you just want to integrate through the COM interface and not make UDFs or use the specialized Excel features, is NetOffice. The project give you a version-independent set of interop assemblies for Office and Visio, and allows you to easily make add-ins targeting different versions of Office. NetOffice can also be used as your COM interop library in an Excel-DNA add-in.
Both of these directions will work fine under the Express editions of Visual Studio, as well as in the free SharpDevelop IDE.

PowerPoint version compilation

Let's say I am using SharpDevelop/VS to develop an app that uses PowerPoint.
Do I need to recompile the app so there is a build for each version of MS Office?
I have MS Office 2007, but I would also like the app to work with Office 2003 and later, without having to recompile the app for each version.
Do I just need to install the appropriate Office Interop redistributable package/msi on the client machine, and ship my app as is?
Thanks in advance for your help.

If you're using the Microsoft.Office.Interop libraries you just need the 2007 version, it will be backwards compatible with older docs

I have found that you should build against the oldest MS Office you have. We still use MS Office 2000.
The the thought behind this:
Everything MS Office 2000 can do any later version of MS Office can do.
A lot of things MS Office 2007 can do is impossible to do in earlier versions
of MS Office.

I absolutely agree with Nifle. Use the OLDEST ones you can find. If you use 2007, there is a very good chance it will not work with older versions.
Since I did not want to install the oldest Office version on my development PC, I used Virtual PC to create a "final build" environment. I develop with my regular PC then move the source files over to the Virtual PC with Office 2003 and VS installed, and create the final customer build there.
You will need to edit the CSPROJ file to reference the older Office libraries with this method. You can do that by just opening VS on the build virtual PC, removing the references to Office and adding them again.

Just to confirm this with anybody that is trying this. I have a .NET 4 project that references the 15.0 PowerPoint Interop library and the Office 15.0 library (Office 2013). I setup the project to "Embed the Interop Types".
I setup a virtual machine with Office 2007 Ultimate on and ran the application (without copying any additional DLLs). It correctly interacted with PowerPoint to extract the data my application was looking for.
The Interop libraries are backwards compatible from my experience.