I'm using EPPlus library to create spreadsheets (reports). In my app every new document first opens an older report to get previous results. The problem is when getting data from cells containing formulas - unfortunately EPPlus doesn't have a calculating engine. To make it work I need to open the old report in Excel, save changes (formulas are calculated), and then new report is created properly. If i don't do it, then the values from formula-cells are blank.
Is there a way to simulate (not doing it manually, but with code)
opening, calculating, closing an excel spreadsheet without excel
installed?
Any ideas how to workaround it?
EPPlus can calculate formulas from version 4. See this page - https://epplus.codeplex.com/wikipage?title=About%20Formula%20calculation&referringTitle=Documentation
http://www.microsoft.com/en-us/download/details.aspx?id=5124
OpenXML is what I used when I didn't have access to Office.... you can build office documents using it without having Office on your machine.... For me there was a learning curve and a lot of googling to figure things out.
I still don't know all of the ins and outs of it, but it worked for what I needed to do.
"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." ...but at the same time they give a lot of useful links on OpenXML manipulation - worth visiting.
http://www.spreadsheetgear.com/ - but it's very expensive, $999/subscription
NPOI (a C# port of Apache POI - the Java API for Microsoft Documents). The Java version can read calculated values, so maybe C# version also could.
Office Integration Pack - don't know if it can calculate
Related
I am using C# and Selenium WebDriver for automating our web application. The test data will be read from Excel sheets(.xlsx). Being new to C#, I want to know if using NPOI is a good option to read/write data from Excel or using Interop in C# is a preferred. I personally prefer NPOI as I feel it is easier to use. This could be because of my exposure to Apache POI when I used Java and Selenium for automation. Kindly help.
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.
https://support.microsoft.com/en-us/kb/257757
Don't use Office Interop in web environments.
At first, as mentioned already, Interop requires actual Excel application to be installed on server, which is not always a good idea ar may even be not possible at all (i.e. if you are yousing Azure Web Apps). I'm currently working on a project which we have rewritten using Interop, but now are going to migrate to NPOI mainly because of it's speed: some tasks require around 5-8 seconds using Excel Interop, because it actually launches full Excel app and communicates with it via RPC. NPOI works directly with Excel files and today while testing one heave action was performed in just around 300 milliseconds including saving modified workbook to new file.
So if you have to work specifically with old binary .xls files NPOI is good choise. If you are going to work with modern OpenXML files (.xlsx), take a look at https://github.com/closedxml/closedxml
The microsoft solution to office document automation is Open Xml : https://msdn.microsoft.com/en-us/library/bb448854(v=office.15).aspx
My C# Windows application needs to print office documents silently(without popup dialog or open up applications such as Word, Excel ). So I'm trying to find a way to print office documents without office (Otherwise user needs to buy office package also to use my application).
I tried with Aspose.NET but It seems some parts of the documents(such as notes, comments) are getting ignored by this component.
I've also tried to go through Microsoft Office 2010: Primary Interop Assemblies Redistributable. But, as I found to use MS office PIAs, MS office needs to be install in the target computer.
Any ideas where should I look into?
First you should understand, that MSOffice uses a proprietary format, that event he best open-source office software is having problems reading without screwing something up.
My suggestion is - you either take something that does a minimal amount of damage, or require office. One suggestion would be: Microsoft used to make "word reader" and "excel reader", try to see if they are still being released.
Another idea would be to find a free office-to-pdf or office-to-xps conversion software, include it with your program and print.
The most difficult way, in my oppinion, would be to feed the document to some online service, for example skydrive's document reader, and request it to print the file.
Depending on the application, your best bet might be saving the content to Open XML and parsing it (beware there's a lot of bloat in larger documents saved in that format per my experience) or simply saving to PDF.
Another clunkier, but more standalone possibility is to use control.click and such to build an automated clicker that opens content in an external freeware application and prints it. The most compelling option is Microsoft's "Viewer" applications (when available). When that is unavailable for a particular document type, Microsoft suggests OneDrive as a freeware alternative (requires account, internet connection).
Word -- "Viewer" has been retired, look for legacy version or use OneDrive
Excel -- "Viewer" is available
Powerpoint -- "Viewer" is available
If you don't want to use a third party application, that could give you a creative, if clunky route to accomplishing your posted goal. Good luck!
I have a system which does heavy use of excel interop.
this is problematic , because it is deployed at many client sites,
each with his own unique operating system, office version , regional settings etc...
This causes me headeaches like this one:
OleDB & mixed Excel datatypes : missing data
It is hard to reproduce or solve this bugs.
Also, I can't run my system as a windows service, because of known issues with using interops at a windows service.
So what I'm looking for is a tool which will allow me for excel import\export without me using the interop. it should ideally:
Support excel 2003 - 2013 and hopefully upcoming versions
Support getting values and writing values to excel (of course)
Support styling operations (font , range of cells, borders, etc...)
Support use of graphs in excel
Support macros activation.
support csv files
This is all I can think of for now :-)
Would appreciate any help. Thanks.
Office Interop can cause a compatibility problems, you need to have a valid office license installed and... is slow...
Probably the best Open solution is to use the Open XML SDK. It's well documented and Microsoft encourages the developers to use this approach over Interop.
I'm trying to develop a c#/asp.net application to extract data from a SQL server and have it formatted in an excel spreadsheet. I have been practicing with excel object model and recently stumbled upon this: http://support.microsoft.com/kb/257757 Considerations for server-side Automation of Office
From what I understand I really can't use Excel Object models? And if not what are other solutions/advice besides whats suggested in this article and 3rd party apps I can use?
From that article:
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.
What this means is that Microsoft won't explicitly prevent you from trying (the licensing allows you to try.) However, if there is a problem, it's up to you to figure out how to fix it.
There is a better option:
Create Excel (.XLS and .XLSX) file from C#
This will allow you to create the file for download without having to use Excel automation on the server side.
I can recommend the SpreadsheetGear library, it has all the Excel functions in one managed dll:
http://www.spreadsheetgear.com/
You 'can' use Excel automation on the server side. However you will be breaching licences ,may run into security problems and generally experience other odd behaviour, especially if you have more than one user using it at a time. I would suggest that you dont do it.
If the data you want to write is simple enough just do it as a csv
If not and you really have to write a spreadsheet look for a 3rd
party component that writes excel files. I only know of one off
the
top of my head and thats Aspose.Cells, but that is quite
expensive.
I have an asp.net website that will generate some excel files with 7-8 sheets of data.
The best solution so far seems to be NPOI, this can create excel files without installing excel on the server, and has a nice API simillar to the excel interop.
However i can't find a way to dump an entire datatable in excel similar to CopyFromRecordset
Any tips on how to do that , or a better solution than NPOI ?
I think NPOI is a good solution, you do not want to be doing interop with Office on a server based environment like ASP.NET, it is just not designed for it and it will fail. In fact MS does not support this, I will update with a link.
As for NPOI our team has used it for something very similar and I know that they wrote a routine to dump the datatable so I assume that this means NPOI does not have that capability natively.
Basically what you will need to do is enumerate the values in each row of the DataTable and write the value out, it should be a reasonably simple routine to write.
Update: The link I promised.
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.