Error Office.Interop.Word on Windows Server 2019 - c#

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.

Related

Using Interop Library for Web Server Side Excel Creation

I am trying to create excel files using interop library, but below is the error I get:
Creating an instance of the COM component with CLSID {00024500-0000-0000-
C000-000000000046} from the IClassFactory failed due to the following error: 8001010a
The message filter indicated that the application is busy.
(Exception from HRESULT: 0x8001010A (RPC_E_SERVERCALL_RETRYLATER)).
I looked into lots of resources out there on the net, which broadly can be categorized into following:
Interop libraries are specifically built for desktop applications, and using them in a server side web application such as wcf is highly not recommended.
Permission issues related to interactive user or DefaultAppPool.
so and and so forth.
Well, here's the caveat, I cannot change the server side application and everything works everywhere else. Few days ago, office 2016 got pushed on my machine from IT, and things stopped working (with above error) on my local machine. Now I can't go and change a legacy code, but see if I can fix the issues on my local to do further development.
Here's what I did, please note that everything was working on this machine (when office 2013 was there):
Got office 2016 Uninstalled, and re-installed office 2013, same issue, hence reverted back to office 2016. Currently MS-Office 2016 32 Bit is installed.
Verified permissions on various sections of security tab of Microsoft Excel Application, have added IIS AppPool\DefaultAppPool user, IIS_IUSRS, Interactive User with full control permission, (shouldn't the error be "Access denied", had permissions been wrong?)
Created a new sample web application, to quickly debug, ran it in all combinations of cpu platform i.e. x86, AnyCpu, x64 - same issue.
Interestingly enough, it works if I point my sample application to IIS Express instead of Local IIS.
Added latest version of interop assembly available (Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1000) - still same issue
Added Microsoft Office 16.0 Object Library (2.8) to the project - still same issue
It's an age old question and its probably better to get away with interop, but I wanted to understand what might be going wrong - all the direct results for the error above suggest implementing IMessageFilter or what not, but I cannot change server side code, below line should simply work as it used to few days ago:
Microsoft.Office.Interop.Excel.Application l_ExcelApp =
new Microsoft.Office.Interop.Excel.Application();
but it doesn't, so what changed? what might have gone wrong?
Also, if it helps - ApplicationID listed in dcomcnfg (/32) is : 00020812-0000-0000-C000-000000000046}, but error has a different one.
Where to look? I hope answer to this question can guide lost souls for ever about this issue.
I'd recommend using the Open XML SDK for dealing or generating open XML documents on the server-side, see Welcome to the Open XML SDK 2.5 for Office for more information. Or just use any third-party components designed for the server-side execution.
As you already noticed, the Considerations for server-side Automation of Office article states the following:
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.
Finally I was able to resolve my issue. Following works:
Web Application hosted in IIS, creating excel documents.
So it turns out, apart from the permissions, it is also very important that the application architecture should be similar i.e. my application was 64bit (running as Any CPU on 64bit OS). Whenever you run into such an issue, make sure following also (apart from setting right permissions to right user):
Make sure the architecture of the two applications i.e. (your own and excel) are in sync. One quick way to know whether your excel is 64bit or 32 bit is by looking into Task Manager running programs. If excel is listed as EXECEL.EXE*32 then your office is 32 bit.
When you install a new version of excel, make sure you completely remove previous versions (and not just uninstall, but also removal of dcomconfig office entries i.e. by deleting any registry entry you can find in regedit for the involved office applications guid, specially excel).
I made it work by removing Office 2016 completely as described in 2, afterwards installing Office 2013 and fixing Microsoft.Office.Core reference accordingly in my code.
Permissions that I assigned was following:
Application Identity - Interactive User
And inside Security tab, added IIS AppPool\DefaultAppPool user to all sections and gave full permission.
My app runs in ApplicationPoolIdentity inside IIS.
If doing all the above, still doesn't fix your problem, then God be with you, and more power to you for your journey towards open XML.

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.

Categories