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.
Related
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).
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.
I've written a program which shifts data around between Access, Excel and some other programs. I have office 2016 and have used the associated comm references in my code. I've used clickonce to deploy. Works fine on my computer. And when deployed to others with different versions of office it also works fine.
However after being used on a computer with a different version of office, similar programs which previously worked on that computer no longer work. I believe this may be because when my program is installed, it registers the 2016 version of office dll's on the local computer, which, at least in the case of access, are not backwards compatible. The solution is to open the old programs as administrator, which I understand allows those programs to reset the registered dll's to whatever version of office they are built on, but means my program no longer works.
First I looked at reference isolation but I now understand Microsoft will not allow you to isolate any office dll's. Any ideas on how to prevent my program from interfering with other similar programs on users computers.
below is the error message when older programs run:
"can't be started.
was unable to initialize the Windows Registry.
Rerun Microsoft Access or Microsoft Office Setup to reinstall."
This is a known issue from running mixed versions of Access (and Office) on a machine.
You may get around it by using a runtime version of Access on the other machines, but as you shifts data around other Office applications, that option may not fit your scenario.
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.
I'm using this guide as a basis for what I'm doing:
http://www.codeproject.com/KB/files/generatepdf.aspx?fid=1517061&select=2903150&fr=1#xx2903150xx
I am using the Open Office CLI bridge to try to create an ASP Generic Handler that will download a file from an MS SQL database, convert it to a PDF, and send it back to the browser or app that requested it.
Here's what I've tried:
The Service shown in that article (including adding the OO.org 3 fixes).
Moving the relevant code directly into the Web Service and Switched IIS to run the 32bit .Net runtime (required for OO.org).
Creating a command line tool that performs the conversion and then spawning a process that runs the tool and waits for the Exit code (0 = success, 100 = failure a, 200 = failure b, so on and so forth)
So far all of these work when debugging the code using the development ASP server that Visual Studio provides. What doesn't work is deploying it to my development server and trying to run it there. I can get processes to run no problem, including OpenOffice's soffice.exe and soffice.bin, but under none of those circumstances does the conversion actually occur. I've tried giving the IIS service the ability to interact with the shell and trying to run the process under my own credentials (works under VS's ASP.net server but not on my dev server) but neither was fruitful.
This has been rather frustrating to be so close yet so... far. Any help figuring this one out would be appreciated. My guess is there's some IIS/ASP.net configuration option that I'm missing. My development and production environments use VS2008 and IIS6 under Windows XP 64bit.
Thanks,
Max
Have you actually installed OpenOffice on your production machine. I know that sounds big, but I have had a similar issue when dealing with MS Office. Regardless of whether I copied the appropriate files across they weren't registered.
Hence installing MS Office solved the issue. However I am sure if you register the appropriate files it would work as well. Maybe as a quick test deploy it on a machine without Open Office installed and see if it works, then install Open Office and see if