We Keep Coding

Excel Interop on build server

I am writing an application that do Excel 2013 Interop.
My first step was to add the reference using the add reference > com panel. But the build on my jenkins failed because Office is not installed on the server.
It is out of the question to install Office on the server but I looked for Office 2013 PIA (like suggested on this post and so many other on the internet), but I could not find it.
So I ended up installing the nuget package for it. It was fine except that it does not install the Microsoft.Office.Core dll required for example to add picture to a worksheet... And I need that feature...
Do you know where I can find the Microsoft.Office.Core.dll or the
Office 2013 PIA?
Or do you have any other solution that could do the trick without
rewriting all the code that currently works?

Recommend you to use OpenXml, which is easy-to-use and will not require you to install Office.

You could add agents (one or more) that are Windows machines with the necessary libraries installed, then configure the master node to only run builds that are specifically assigned to it.
Then you don't need to install the Excel 2013 development environment on your server, and your build environment will more closely represent the user environment.
Refer to How to set up new Jenkins slave (where "slave" is the out of favor term for an agent)

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 the Open XML SDK if you deal with open XML documents only, see Welcome to the Open XML SDK 2.5 for Office. Or just any third-party component designed for the server-side execution (for example, Aspose).

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.

PowerPoint Add-in working on Windows 7 Enterprise edition but not on Windows 7 Pro

I have created a PowerPoint add-in using C# VSTO and using msi installer for the deployment.
The Problem is that on every system at my end(all Windows 7 Enterprise edition), the plug-in is working fine, but on users' machines(Windows 7 Pro) either the ribbon is not visible or the events are not working.
My concern is, am I missing something which I need to take care of during the development?
Thanks

This is one of the reasons that VSTO deployment is a pain. You have to understand every dependency of your application and the dependencies of your dependencies and then make sure you cover all of them for every version, flavor and bitness of windows and office that you can think of. Then you come to find out that a user has a Click To Run version of Office installed that generally doesn't support AddIns anyways.
VSTO Lessons Learned
VSTO 4 ( 2010 ) Lessons Learned
Office 2010 Bitness Pain
There are so many possible failure points in the chain that no one could possibly tell you the cause of your problem. A lucky guess perhaps but that would be it. To date I've created VSTO installers for 6 companies and even with my background knowledge and prebuilt templates they are still labor intensive projects because of the test surface that is involved.

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?

Using Office 2007 PIA's against OpenOffice.Org

I have been using Office 2007 PIA's to run PowerPoint files in my C# application.
I know that this requires Office 2007 to be installed on the machine.
I wanted to know, can the same set up be run with OpenOffice.org installed instead of Microsoft Office?
Note: I am using a Qindows machine.

While OpenOffice does have an Automation Bridge which allows you to access OpenOffice applications in Automation (a proper subset of COM which in turn you can access through COM Interop), the API profile is most definitely not the same.
That being said, any code that you write which uses the Office 2007 PIAs will not be compatable with the Automation model provided by OpenOffice.
Granted, you can probably do many of the same things that you could do in Office, it's just the way you would go about doing them (the methods you call) would be completely different.

In a word, No.
The PIAs contain mapping information specific to the DLL that they wrap, in your case MS Office application DLLs.