We Keep Coding

Error Office.Interop.Word on Windows Server 2019

I have a problem with .NET app, where application not working correct on the Windows Server 2019. Problem is in using Microsoft.Office.Interop.Word library. On the server is installed and activated Office 2019 and Word run normally.
The interesting thing is that if I start application as console application with exe file, so everything runs and process is completed correct, but if I try to run the application with Task Scheduler or i changed application to Windows Service, so application return exception. Exception occurs in the moment, when the application trying create or add a document Microsoft.Office.Interop.Word.Application.Documents.Add(...).
I used the same processes (application) on older Windows Servers with MS Office and everything runned correctly without exceptions.
Do you have idea, where can by a problem? Some permissions?
I tried different steps and configuration, but not working.
For example I created folders "Desktop" in
C:\Windows\System32\config\systemprofile
C:\Windows\SysWOW64\config\systemprofile
or I changed basic permissions Office DCOM in Component Services. But nothing helps.
Thanks a lot.
Exception:
System.Runtime.InteropServices.COMException (0x80010105): The server threw an exception. (Exception from HRESULT: 0x80010105 (RPC_E_SERVERFAULT))
Code:
appWord = new Application();
appWord.Visible = true;
wordDocument = appWord.Documents.Add(Template: Path.GetFullPath(...), Visible: false);
appWord.Visible = false;

if I try to run the application with Task Scheduler or i changed application to Windows Service, so application return exception
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. Otherwise, you may take a look at third-party components designed for the server-side execution.

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).

Excel Automation through Windows Service written in C# fails in Office 365 installed machines

I am working with Windows Service written in C#. Through this Windows Service I am automating Excel in a programmatic way.
Excel.Application excel = Excel.Application();
This code was working fine with all versions of Excel (2003, 2007, 2010, 2013).
Recently I have installed Office 365 in my machine. Suddenly I am getting below exception when I automate the Excel using above call:
Retrieving the COM class factory for component with CLSID {00024500-0000-0000-C000-000000000046} failed due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 (CO_E_SERVER_EXEC_FAILURE)).
Can anyone let me know, is there any special consideration should be taken when automating the Office 365 Excel via Windows Service?

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.
You may consider using the Open XML SDK instead, see EWS Managed API, EWS, and web services in Exchange for more information. Or any third-party components designed for the server-side execution.

Error when creating Excel file from asp.net

I am trying to create an excel file using c#. My code is working fine on windows server 2008 but I am getting error in window server 2012 R2, iis server 8.5, ms office 2007 standard.
Its telling me error on line
oWB = (Excel._Workbook)(oXL.Workbooks.Add(Excel.XlWBATemplate.xlWBATWorksheet));
error: [COMException (0x800a03ec):microsoft office can not save or open more documents.

You are trying to create an Excel file
using COM automation
from an ASP.NET application.
This combination is officially unsupported by Microsoft:
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.
Thus, if it worked so far on your Windows Server 2008, it was a mere coincidence. You have been lucky. It's not something you should do on a production system.
To create an Excel file from ASP.NET, use one of the various other solutions available:
Create Excel (.XLS and .XLSX) file from C#
(Personally, I have good experience with SpreadsheetLight, but any of the other solutions is fine as well.)

It's possible that it isn't a problem with your code since it works fine with windows server 2008. You can try this registry hack, but keep in mind that wrong registry modification can be fatal so you might want to create restore point or backup of your registry:
Run > regedt32
Fix the value of: HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders
In your User Shell Folders select Cache key and assign it to your own directory
There are also solutions I found for your problem without registry modification, visit this link or this one, it might help you. If none of these things work for you try googling "microsoft office can not save or open more documents" and check problems related to the excel itself. Once again, I assume the problem is not inside your code.

Problems with office automation in asp.net. I can use alternatives such as open-office, if I knew how

I have a ASP.NET 2.0 web application that should upload a ppt file and then extract its slides to images. For that I have imported office.dll and Microsoft.Office.Interop.PowerPoint.dll assemblies and wrote the following code
public static int ExtractImages(string ppt, string targetPath, int width, int height)
{
var pptApplication = new ApplicationClass();
var pptPresentation = pptApplication.Presentations.Open(ppt, MsoTriState.msoTrue, MsoTriState.msoFalse, MsoTriState.msoFalse);
var slides = new List<string>();
for (var i = 1; i <= pptPresentation.Slides.Count; i++)
{
var target = string.Format(targetPath, i);
pptPresentation.Slides[i].Export(target, "jpg", width, height);
slides.Add(new FileInfo(target).Name);
}
pptPresentation.Close();
return slides.Count;
}
If I run this code in my local machine, in asp.net or a executable, it runs perfectly. But If I try running it in the production server, I get the following error:
System.Runtime.InteropServices.COMException (0x80004005): PowerPoint
could not open the file. at
Microsoft.Office.Interop.PowerPoint.Presentations.Open(String
FileName, MsoTriState ReadOnly, MsoTriState Untitled, MsoTriState
WithWindow) at PPTImageExtractor.PptConversor.ExtractImages(String
caminhoPpt, String caminhoDestino, Int32 largura, Int32 altura, String
caminhoThumbs, Int32 larguraThumb, Int32 alturaThumb, Boolean geraXml)
at Upload.ProcessRequest(HttpContext context)
The process is running with the user NT AUTHORITY\NETWORK SERVICE. IIS is configured to use anonymous authentication. The anonymous user is an administrator, I set it like this to allow the application to run without having to worry about permissions.
In my development machine I have office 2010 beta1. I have tested with the executable in a pc with office 2007 as well. And if I run the code from the executable in the server, with office 2003 installed, it runs perfectly.
To ensure that there wouldn't be any problems with permissions, everyone in the server has full access to the web site. The website is running in IIS7 and Classic Mode.
I also heard that Open-office has an API that should be able to do this, but I couldn't find anything about it. I don't mind using DLLImport to do what I have to do and I can install open-office on the web server. Don't worry about rewriting this method, as long as the parameters are the same, everything will work.
I appreciate your help.

Don't ever use Office Interop from an ASP.NET application. See Considerations for server-side Automation of Office.
However, if you have no alternative, on Windows Server 2008 you need to create the following directories to get this to work:
Windows 2008 Server x64: C:\Windows\SysWOW64\config\systemprofile\Desktop
Windows 2008 Server x86: C:\Windows\System32\config\systemprofile\Desktop

When considering using Office Automation on the server, you might want to take a read through the info in the following KB article.
http://support.microsoft.com/kb/257757
A key phrase from the above link
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.
And I can confirm that the above is very true, and not just MS trying to discourage you...

In my situation (converting presentation to video, and I have very similar problem with open stuff) this helps:
Creating the following directories:
C:\Windows\SysWOW64\config\systemprofile\Desktop
C:\Windows\System32\config\systemprofile\Desktop (I don't have this)
My operating system Windows Server 2012 R2 Standard

The Interop libraries require that the application in question be installed on the machine from which they are running. I.e., in order for this to work on your production server, you will need to have Office installed on that server. This is generally an awful idea. There are many issues with type of setup as each time someone makes a request, a new instance of the application in question (in your case PowerPoint) is launched.
If you want to parse PowerPoint files on a central server, then you should use a library that reads PowerPoint files. I know that Aspose makes such product (Aspose.Slides) but there are others as well.
If the documents are in PowerPoint 2007, you might be able to parse the Open Office XML for the data you want. See Introducing the Office (2007) Open XML File Formats and Open XML SDK 2.0 for Microsoft Office for more.

I might be wrong, started looking into a similar thing recently. But you should not need office installed on a machine to create or edit 2007+ office files. They are basically zip files with a different extention. If you rename it to .zip you should see all the files and be able to edit them directly.
It can then be unzipped and all the files are there for you. You can create new files in a similar fashion

Don't ever use Office Interop from an ASP.NET application. See Considerations for server-side Automation of Office.
However, I just wanted to note here that I had to do the fix described by Murthy Pantham on a Windows 7 Professional 64 bit machine with Office 2010. It did not have Windows 7 Service Pack 1 or Office 2010 Service Pack 3 installed. So the lesson here is apparently that fix is not limited to Server 2008. Hope this helps someone.