We Keep Coding

Why is Word Interop complaining of a "class not registered" error, when Excel interop doesn't?

We have an application which has been around for some time and which uses the Excel Interop library. The project references the Microsoft.Office.Interop.Excel and it's pointed at the default path in Visual Studio.
Recently I was asked to add some functions to this project based on Word interop. This all went fine in development. I add a reference to the Word interop dll at the same location (C:\Program Files (x86)\Microsoft Visual Studio 12.0\Visual Studio Tools for Office\PIA\Office15).
Both Word and Excel are installed on the server. However, while the Excel interop continues to function, trying to use the Word functions throws this error:
System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {000209FF-0000-0000-C000-000000000046} failed due to the following error: 80040154 Class not registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
References to this error suggests it's due to a 32/64 bit clash, which I find quite surprising. The dll is 32-bit and the project build target is "Any CPU". And besides, it runs the 32-bit Excel interop without complaint.
As far as I can tell, neither Word on Excel have interop dll's installed in the registry on the server.
What gives here? Is this really down to an architecture mismatch? And if not, why is my application able to utilise the installed Excel interop but not the Word one?

Interop files shouldn't be registered on the server, they are not COM servers. Instead, I'd suggest re-installing Office applications (repairing them) to make sure all the required windows registry keys for COM servers were created and exist at the time when you try to automate them.
Otherwise, you have faced with a well-known issue... Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a possible workaround you may consider using Open XML SDK or just any other third-party components designed for the server-side execution.

This is a difficult problem as the scenario is not supported by Microsoft. Reference: Considerations for the server-side automation of office .
Try changing the setting of "Embed Interop types" in the properties for the refrence to the Office library. That makes the code independent of the PIAs of any specific application version and could work-around whatever is the problem with the server-side installation.
PInvoke (GetType.InvokeMember) also makes the solution independent of the application version and it could be used throughout. This is more work, though, since you don't get Intellisense.
There are a few known issues with this embedding interop types, as there are a couple of "hiccups" in how the embedded interop types embed the information (differently than how the PIAs are constructed). In this case, it might be necessary to use PInvoke for the problem methods/properties. The two approaches can be combined.

How do I release an Office Add In to the Windows Store

I've created an office add in using Visual Studio 2015. The add in works perfectly with MSProject in debug mode.
I've published the add in following the instructions here. So far so good.
Now I'd like to release it to the Microsoft Windows Store. I've logged into the Seller Dashboard and I pretty much fall at the first hurdle.
It asks for the app package manifest file. TBH I'm not sure which file it wants exactly, so I tried
xxx.OfficeAddin.vsto file in the root of the "publish" directory
xxx.OfficeAddin.dll.manifest in the publish/Application Files/xxx.OfficeAddin_1_0_0_2 directory
xxx.OfficeAddin.vsto
also within the publish/Application Files/xxx.OfficeAddin_1_0_0_2
directory
I assume it wants No2 but it didn't work so I tried them all. None of them work and all result in the same error:
Your manifest does not reference any supported Office Add-in namespace. The most recent version is http://schemas.microsoft.com/office/appforoffice/1.1.Learn More
Googling this error in quotes returns nothing, without quote - a load of unrelated results.
I'm completely stumped now - has anyone managed to do this?

You cannot add VSTO desktop applications to the Windows store, but may be able to do so soon.
The Windows Store was designed for installing applications that would run in private sandboxes that would keep apps isolated (in case of issues) from your operating system and other applications. However, Desktop applications often have registry entries, dll dependencies, and other client-side requirements. Because the Windows Store cannot accommodate these OS-related and client-side requirements, desktop applications cannot currently be distributed via the Windows Store
Fortunately, Microsoft is finally addressing this issue. They are in the process of finalizing Project Centennial, which will allow one to convert desktop apps for distribution via the Windows Store. It does this by providing a separate registry for desktop apps and a way for dlls to function without hurting other applications.
As of this writing, Microsoft has withdrawn the preview version of their Project Centennial Desktop App Converter. I am hoping this is in preparation for releasing a stable version.
Will Project Centennial allow VSTO add-ins to be sold via the Windows Store? I am hopeful, but this is not certain. We should know more within the next couple of months, if not sooner.
Update: June 8, 2016
At Microsoft's dotnetConf 2016 John Sheehan stated that VSTO add-ins would not be supported in version 1 of Project Centennial. He added that plug-ins (his term) that leveraged other desktop technologies would be able to be converted by the Project Centennial Desktop App Converter some time after Project Centennial's initial release (now slated to be concurrent with Window 10's 1st anniversary release in July 2016). Mr. Sheehan did not elaborate on whether VSTO add-ins would specifically work with later versions of Project Centennial, but he did indicate that compatibility with software that leverages other desktop technologies is definitely on the Project Centennial road map.

How to creating an addin for multiple Office programs?

I want to develop addins for Office (Outlook,Word and Excel). The code will be almost the same. The difference is only for retrieve a document (mail for Outlook, document for Word,graphic/chart for Excel.
Should I develop 3 addins and therefore I will have 3 installations for my users. Or can I develop only 1 addin and add a condition somewhere?

Yes, that is possible. You possibly need 3 different AddIn classes, since every platform has it's own format and parameters and you might want to deviate some logic, though there is nothing to stop you integrating the three add-ins in one.
Another option is to make a class library that only uses the general Office assembly, and include that library into your other projects.
For the deployment: you can't use ClickOnce out of the box for that, since ClickOnce only supports a single Office program per installation. You can tweak the installation though, as explained on this article on MSDN: Deploying Multiple Office 2010 Projects in One Package.

VSTO doesn't supoport creating multi-host add-ins. The possible ways are:
Develop an add-in which implements IDTExtensibility2 interface without VSTO.
Use third-party tools such as Add-in Express that support creating multi-host add-ins.
Adding multiple AddIn classes to the extisting VSTO based add-ins is not a convinient way to go. At least, you will not be able to debug the code

support different Office versions with Office Automation

We created an application that uses Office 2007 (Excel 2007) to read in data from an Excel worksheet. However. I noticed that when I want to deploy the application on a system with Office 2003 installed, it crashes because other PIA's (and other dll's) need to be referenced for this version of office.
Do I need to compile different versions of my application to be able to support different versions of Office or is there a more elegant solution for this problem?
I use Visual Studio 2010 (C#) and the .Net 4.0 platform.

As you're using .NET 4, you can use "embedded" PIAs (aka "No PIA"). Change the option on the Office reference so that "Embed Interop Types" is True.
So long as you only use features of Office which are supported on the machine you deploy on, you should be fine.
It also means that:
- You don't need to worry about the PIA itself not being present on the target machine
- Any methods or properties which are of the VARIANT type in the original COM interface are now represented using dynamic in your code, which can make your life simpler

Depending on whether you have any other requirements (you say reading data from excel), you can use the OLEDB driver to connect to the excel file and query it in a SQL manner.
Example:
http://codehill.com/2009/01/reading-excel-2003-and-2007-files-using-oledb/

You can reference the PIA's for multiple versions of office, and figure out at runtime which to route your calls from.

Is there a way to automate MS Office applications without license?

I am currently writing an application that will perform automation in Excel. I have MS Office (2007) installed on my work computer and the application is working fine referencing the the Microsoft Excel 12.0 Object Lirary.
The target machine has the Office installed but not registered. It is one of those preinstalled editions. Attempting to run the application on the target machine I get an error saying Office is not installed?
I'm assuming then you have to have a registed Office to use the object libraries? Is there anyway around this as I do not have a Office license key lying around and its quite expensive?

See if you can run Excel manually on that machine. If you can do this, you should be able to automate it as well. If you cannot, don't expect to be able to somehow miraculously (and legally) to make it work through automation. Automating Office through its object library is no different than using it through the UI. You need to have a licensed and properly installed copy of Office in order to be able to use it.

Nothing comes for free.
Current licensing guidelines prevent Office applications from being used on a server to service client requests, unless those clients themselves have licensed copies of Office
What are you trying to automate/achieve? Don't you think OpenOffice would be of any use?