I am using Microsoft Office Excel Interop to create an excel file in ASP.NET C#. Everything is successful when I am running application in Visual Studio 2010. I have published my web application in my own IIS server, it is ok. But when I publish application in Windows Server 2008, the problem was detected.
I looked for much in internet and i have done following, but the problem still was not solved:
I have set Application Pool Identity to LocalSystem. In Run -> mmc -32 -> Component Services -> My Computer -> DCOM Config -> Microsoft Excel Application -> right-click -> Properties window: in Identity tab, I have checked all radio buttons in this window.
I have set Application Pool Identity to NetworkService, and I have checked all previous radio buttons again.
In Run->mmc -32 -> Component Services -> My Computer -> DCOM Config -> Microsoft Excel Application -> right-click -> Properties window: in Security tab: I gave Local Launch and Local Activation for INTERACTIVE, NETWORK SERVICE, IIS_IUSRS users.
Here is my code which I used Interop Excel:
Excel.Application xlApp = new Excel.Application();
object misValue = System.Reflection.Missing.Value;
Excel.Workbook xlWorkBook = xlApp.Workbooks.Add(misValue);
Excel.Worksheet xlWorkSheet = (Excel.Worksheet)xlWorkBook.Worksheets.get_Item(1);
Workbook.SaveAs(Server.MapPath("DownloadFolder\\" + fileName + "_siyahi.xls"));
I found my problem. In my Windows Server system regional settings haven't been United States and I have set worksheet.cells.NumberForm="0.00" in my code.
xlWorkSheet.Cells[rowNumber, 4].NumberFormat = "0.00";
Server doesn't knows this number format. I have changed Format to English (United States) and Current location to United States and my problem solved.
Related
I'm having issues with saving an excel spreadsheet when running on the Windows server 2008 and 2012 but this project its working on local pc (Windows 7,8 or 10)
C# source code
Microsoft.Office.Interop.Excel.Application excelApp = new Microsoft.Office.Interop.Excel.Application();
Microsoft.Office.Interop.Excel.Workbook excelWorkBook = excelApp.Workbooks.Add();
Microsoft.Office.Interop.Excel.Worksheet excelWorkSheet = excelWorkBook.Worksheets.Add();
excelWorkSheet.Name = "blablabla";
//added cells data
excelWorkBook.SaveAs(excelPath.ToString());
excelWorkBook.Close();
excelApp.Quit();
error message
Exception from HRESULT: 0x800A03EC
System.Runtime.InteropServices.COMException (0x800A03EC): Exception
from HRESULT: 0x800A03EC at
Microsoft.Office.Interop.Excel._Workbook.SaveAs(Object Filename,
Object FileFormat, Object Password, Object WriteResPassword, Object
ReadOnlyRecommended, Object CreateBackup, XlSaveAsAccessMode
AccessMode, Object ConflictResolution, Object AddToMru, Object
TextCodepage, Object TextVisualLayout, Object Local)
Installing MS office in servers to run office.interop assemblies in u r project is the best option..
Again if u don't want to install MS office at all on server machine, Then u can install PIA (primary interop assemblies)
http://msdn.microsoft.com/en-us/library/kh3965hw.aspx
download link for PIA for office
http://www.microsoft.com/downloads/details.aspx?FamilyID=59daebaa-bed4-4282-a28c-b864d8bfa513&DisplayLang=en
This error is due to the fact that the local pc and the server have different office versions.I used the office 2012 references (microsoft office interop excel 14) but the server has a different version (microsoft office interop excel 12)
Step 1) I installed the same office versions. (v.12)
Step 2) Select "The interactive user" option in "Microsoft Excell Application Properties" window.
https://msdn.microsoft.com/en-us/library/windows/desktop/ms686587(v=vs.85).aspx
This issue isn't caused by your code. My computer had both Office 2016 and 2010 on it, and after uninstalling 2010 and rebooting, the issue was fixed. Make sure to change the Application Reference to MS Office 14.0 Object Library (for Office 2010).
I have gone to hell and back with Microsoft.Office.Interop.Excel.Workbook and I found that the fix to not use the C:\ drive on my AWS windows system but the D:\ drive. Something about the how the C: drive was mounted was breaking the Microsoft.Office.Interop.Excel.Workbook SaveAs2 function call. I tried a lot of other common fixes found online but this was the only thing that worked.
Excel.Workbook xlWorkbook = xlApp.Workbooks.Open(pathExcel, null,false);
need open readonly = false
I am attempting to capture some data from Excel from within a C# console application.
I get the error
Unable to cast COM object of type 'microsoft.Office.Interop.Excel.ApplicationClass' to 'microsoft.Office.Interop.Excel.Application'"
This code used the 'Microsoft Excel 12.0 Object Library', and I included a reference to 'Microsoft.Office.Interop.Excel'.
I dug a little bit this site and came across
Interop type cannot be embedded, but I could not understand it enough to implement what was suggested as a solution.
My .NET version is 4.5.
using System;
using System.Collections.Generic;
using System.ComponentModel;
using System.Data;
using System.Drawing;
using System.Linq;
using System.Text;
using Excel = Microsoft.Office.Interop.Excel;
namespace deneme
{
class Program
{
static void Main(string[] args)
{
Excel.Application xlApp = new Excel.Application();
xlApp.Visible = true; // <-- excel application
xlApp.DisplayAlerts = false;
// Open the workbook.
Excel.Workbook wBook = xlApp.Workbooks.Open("C:\\FNN\\XLA\\fnnComTemplate.xlsx",
Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing, Type.Missing, Type.Missing,
Type.Missing, Type.Missing);
// get the sheet
Excel.Worksheet wSheet = wBook.Sheets[0];
// foreach (Excel.Worksheet sheet in wBook.Sheets) { if (sheet.Name == "templateSheet") { wSheet = sheet; } }
Excel.Range rng = wSheet.get_Range("A1");
aux = wSheet.Range["F6"].Value;
Console.WriteLine("interop result:" + aux);
Console.ReadLine();
}
}
}
For Microsoft Office 365 in Windows 10
I was running Microsoft Office 365 with Windows 10 and tried the mentioned solutions to remove the registry key without success.
I went to Settings -> Apps in an attempt to repair the Office 365 suite:
To get there you can follow these steps:
Open Start
Select Settings
Select Apps
In the default page, Apps & features, search for Microsoft 365
Select "Microsoft 365"
Select "Modify"
I selected the Quick Repair option:
This resolved the issue for me.
If this is not a code-related error, then please remove the registry key listed below. This issue is caused by the key being left over from a higher version of Office.
Steps:
Go to Start
Select Run
Type regedit and hit Enter
Navigate to HKEY_CLASSES_ROOT -> TypeLib -> {00020813-0000-0000-C000-000000000046} -> 1.9/1.8/1.7
Delete the registry key
A simple repair of Microsoft Office resolved the issue for me.
A machine had been updated to Office 2016 64-bit and the COM interface was throwing exceptions when called from the a 32-bit application. It did not have old TypeLib entries like the ones in Jayesh's answer.
Comparing ProcessMonitor traces to a working machine with Office 2016 led to what look like dead end registry keys in
HKEY_CLASSES_ROOT\Wow6432Node\TypeLib\{00024..
The working machine would check for the non-existent registry key and return
NAME NOT FOUND
The failing machine had the registry key but then would throw an exception shortly thereafter.
After repeatedly deleting the registry key, rerunning the trace, deleting the next failing key, the COM interface functionality was restored.
Using the exact same code I got the same problem in a laptop when everything worked fine on another one. I tried various solutions found here and there in the internet but what finally worked, was the explicit definition of the use of non 32 bit version of the library. For doing so in visual studio, I had to tick and then untick the box "Prefer 32-bit" in the build section of the project configuration, which added <Prefer32Bit>false</Prefer32Bit> in the .csproj file.
In my case
I delete regedit in:
HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}
delete 1.9
and problem solved.
My setup: Visual Studio: 2019, Office: 2019 x64, Target Framework: net5.0-windows
Nothing help me from error:
Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.Office.Interop.Excel.Application'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{000208D5-0000-0000-C000-000000000046}' failed due to the following error: Error loading type library/DLL. (0x80029C4A (TYPE_E_CANTLOADLIBRARY)).
So I found via Sysinternals Process Monitor a missing file path for Excel.exe in the Registry for Win32 and changed it to the existing x64 version:
[HKEY_CLASSES_ROOT\TypeLib\{00020813-0000-0000-C000-000000000046}\1.9\0\win32]
#="C:\\Program Files\\Microsoft Office\\Root\\Office16\\EXCEL.EXE"
I had this issue in PowerShell. Along with the mentioned issue, $xlApp.Workbooks returned null for me. Running the PowerShell script in 32-bit mode resolved my issue.
I try convert Office documents using Office.Interop running under separate Windows service.
This service is running under specific account (username in future).
All folder access rights is set for this account. And when i try to create any of Office application (for example, var app=new Excel.Application()) then my code fails with exception:
Retrieving the COM class factory for component with CLSID {XXXX} failed due to the following error: E_ACCESSDENIED.
Ok, but i have already configured the DCOM permissions for this CLSID! I open the dcomcnfg.exe , select component with this CLSID, opening settings, security and see that user of this service have all rights for this component.
Why this exception throws?
Ocka guys, i found the answer.
1) Be sure that you have install a right version of Office 2007
2) Be sure that you have install a PDF\XPS addin
3) Just office and its addin installed, you should run DCOMCNFG and pick My Computer->DCOM config. As it turned out, after office installation there is no mappings between CLSID and AppID in registry.
4) Close dcomcnfg window. Now there is right mappings in registry. You should get all things related to office (its id, e.g. {XXXXXXX-XXXX...}) in HKCR\AppID and HKCR\CLSID
5) For all these id's you should grant access, this can be achieved using this algorythm:
* open HKCR\AppID{id} key
* setup LaunchPermission and ActivatePermission values (code to do this find there in stackoverflow)
* Set value "RunAs" as "Interactive User"
Ocka, your office automation should work correctly, if i didn't forget some step..
I have a c# console application running daily as a scheduled task.
Recently I've added a new functionality to send an e-mail with an attached pdf report, using Access 2010 built-in pdf export:
using MsAccess = Microsoft.Office.Interop.Access;
//(...)
AccApp = new MsAccess.Application();
AccApp.Visible = false;
AccApp.OpenCurrentDatabase(DBPathname, false);
AccApp.DoCmd.OutputTo(MsAccess.AcOutputObjectType.acOutputReport, "GMB_CSS_Report", "PDFFormat(*.pdf)", ReportFilename, false, Type.Missing, Type.Missing, MsAccess.AcExportQuality.acExportQualityPrint);
//(...)
When I run the new version interactively on the command line it works well, exporting the report as a PDF to the designated path\file.
But when I run it from task manager, using the same credentials, it crashes on the DoCmd.OutputTo(...) statement with the error:
(System.Runtime.InteropServices.COMException) Microsoft Access can't save the output data to the file you've selected.
That does not make any sense, as the application successfuly writes several other files to the same folder, running either from the console or from the task manager.
I've also found that the application runs without the error as a scheduled task on a third PC, not integrated in the company AD domain (the production and dev hosts are on the domain), even though all 3 hosts have the same s/w level (Win7 SP1, Access 2010 updated to latest patches via Windows Update).
This is bizarre... am I missing something here ? Any suggestions will be greatly appreciated.
Thanks in advance.
I think that your problem is in the "PDFFormat(*.pdf)" constant string.
The right one for PDF is this:
public const string acFormatPDF = "PDF Format (*.pdf)";
And this is for RTF:
public const string acFormatRTF = "Rich Text Format (*.rtf)";
I still have got problems with the same function on a 64Bit version of Access 2010 running on Windows 2008 Server 64Bit, while it works perfectly on a Windows Server 2003 machine 32bit with Access 2010 32bit.
I try open .doc file with interop, when I debug code in Visual studio result is a file but I publish web to IIS result is null.
I'm using Windows server 2012 64bit and Microsoft Office 2007.
Why result in IIS return null and solution?
var wordApp = new Application { Visible = false };
var path = Request.PhysicalApplicationPath + "File\\TestFile.doc";
object srcPath = path;
var wordDoc = wordApp.Documents.Open(ref srcPath);
When you execute the program from the Visual studio then code uses the logged in user to make calls for COM components(Microsoft word). Generally logged in user has permission to execute the calls on the COM component. So code will work in the Visual studio.
When you publish the website into IIS then it uses default user of IIS to make the call to COM component. If that user doesn't have the permission then call fails and throws the exception.
First find out the user that IIS is using. Add that user to the specific COM component and give the permission to execute the calls.
Start > Run > dcomcnfg
Navigate to Component Services > Computers > My Computer > DCOM Config
Locate to "Microsoft Word 97 – 2003 Document" > Right click > Properties
On the security tab: Select all radio to (Use default)