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.
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
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 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
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've done some googling and there seems to be a plethora of tools for reading excel 2007 spreadsheets using c#. I'd like to know which one performs best and is easy to use.
Frankly, it depends on if you have Excel installed on the machine.
If you have Excel installed, using Microsofts Office APIs is as quick and ( for the price ) painless as you are going to get. That said, if you don't have Excel installed, the question gets much trickier.
Also, note, if you are installing to a web server that is available to the world, using Microsoft's Office APIs often isn't actually legal, as the end user needs to have an office license for you to be legal. If this is the case, and you are developing for redistribution or internet deployment, make sure that the library you are considering has no dependencies on the Office APIs, as their redistribution isn't actually legal either. If you need to, for example, provide a viewer for people that don't have Excel installed, you can't legally use the Office APIs, nor can you use 3rd Parties that depend on that layer. Compliant libraries will make it clear in their description that they don't depend on Excel.
It depends what you're trying to do with the spreadsheet.
If you want to read tabular data, OleDB is the best option.
If you want to read formatting or specific cells, you should use a third-party component. (I can't recommend a specific vendor)
You should avoid using Excel's COM object model unless you want to interact with an open window or print a spreadsheet.
I've had pretty good results with Koogra.
Check the Open XML SDK. It includes a "Productivity Tool" that lets you walk through the structure of a document to help write your code as well.
I looked into the Open XML Format SDK about a year ago and it seemed like a good alternative that does not require Office installed.
I have used GemBox and the Microsoft Office APIs to read in spreadsheets. I have had success with both options but I tend to like GemBox a bit more. It is fast and simple to implement but comes with a price tag.