Alternatives to Server side Excel manipulation for .NET
I'm looking for a viable alternative to Excel automation to manipulate, read and create excel files in an ASP.NET website context.
I'm aware of a couple of component builders that support these scenario's:
- Aspose Cells,
- softartisans OfficeWriter
- Spreadsheetgear
But these all have one thing in common, they're very expensive.
I'd prefer a solution that supports both Office 2003 file formats and Office 2007 file formats, but a good solution that only supports either, is no problem for me.
I've also found a few links to System.IO.Packaging, but I haven't been able to find a good tutorial that shows how to create and manipulate excel files, other than through complex XML manipulation.
I'm aware of a couple of component builders that support these scenario's:
- Aspose Cells,
- softartisans OfficeWriter
- Spreadsheetgear
But these all have one thing in common, they're very expensive.
I'd prefer a solution that supports both Office 2003 file formats and Office 2007 file formats, but a good solution that only supports either, is no problem for me.
I've also found a few links to System.IO.Packaging, but I haven't been able to find a good tutorial that shows how to create and manipulate excel files, other than through complex XML manipulation.
ASKER
This is what System.IO.Packaging tries to make simpler, but as I need a less experience developer to build this, I'll need more than just free XML access as the solution...
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
I'm a big fan of Aspose too, but there is no budget in this project for their wonderful components. I feel we should just buy an enterprise license and be done with it, but that's me.
I'll have a look at ExcelPackage, it looks like it might suit our needs perfectly!
I'll have a look at ExcelPackage, it looks like it might suit our needs perfectly!
It really depends how complicated the Excel is.
Simple solution is to send a HTML-table with content-type "application/vnd.ms-excel"
Then there is the single-XML-approach. Office-XML is a special XML-format which can contain many Excel features. It can create multiple worksheets in a file and it really isn't that difficult. You can take a desired Excel file and do "save as XML" to get an example of what it looks like. Don't be overwhelmed by the <styles> section, it seems that excel creates a seperate style tag for every single cell (a big overkill). I use XSLT and XML to create Excel files on the fly this way. Disadvantage is this does not support all features in Excel.
> other than through complex XML manipulation
Not sure how experienced you are with XML, but it really isn't that complicated once you are used to it.
Simple solution is to send a HTML-table with content-type "application/vnd.ms-excel"
Then there is the single-XML-approach. Office-XML is a special XML-format which can contain many Excel features. It can create multiple worksheets in a file and it really isn't that difficult. You can take a desired Excel file and do "save as XML" to get an example of what it looks like. Don't be overwhelmed by the <styles> section, it seems that excel creates a seperate style tag for every single cell (a big overkill). I use XSLT and XML to create Excel files on the fly this way. Disadvantage is this does not support all features in Excel.
> other than through complex XML manipulation
Not sure how experienced you are with XML, but it really isn't that complicated once you are used to it.
ASKER
Multiple worksheets is a requirement I have to deal with, so save as HTML is no option. We also need to read the data back in, where HTML is far from ideal.
I know the XML manipulation isn't that difficult, but its a lot less readable than a few lines of code doing a transfer of data from a database to an object. The source of our data is already in objects (from Linq to Sql).
When doing XML translations we also bumped into issues with merged cells, and objects such as graphs and other things already in the workbook. When you're always creating the files from scratch and don't have to read them back in, your solution sounds ideal, but as we're having to roundtrip them, I'm first going to give ExcelPackage a try.
I know the XML manipulation isn't that difficult, but its a lot less readable than a few lines of code doing a transfer of data from a database to an object. The source of our data is already in objects (from Linq to Sql).
When doing XML translations we also bumped into issues with merged cells, and objects such as graphs and other things already in the workbook. When you're always creating the files from scratch and don't have to read them back in, your solution sounds ideal, but as we're having to roundtrip them, I'm first going to give ExcelPackage a try.
> objects such as graphs and other things already in the workbook
You mean you do not start from scratch? if you have things "already in the workbook".
That makes it all so much easier. Create a connection to your not-from-scratch excel file, and use that connection to fill the workbook from your datasource (for which you need a different connection of course).
You mean you do not start from scratch? if you have things "already in the workbook".
That makes it all so much easier. Create a connection to your not-from-scratch excel file, and use that connection to fill the workbook from your datasource (for which you need a different connection of course).
ASKER
We need to support both scenario's, in fact we need
- to create excel files from scratch
- read these (and similar excel files)
- manipulate existing (either from this app, but also user created) excel files
We also need these to be able to work concurrently and in an ASP.NET context. Which makes OleDb connections to Excel a less than ideal solution, unfortunately...
- to create excel files from scratch
- read these (and similar excel files)
- manipulate existing (either from this app, but also user created) excel files
We also need these to be able to work concurrently and in an ASP.NET context. Which makes OleDb connections to Excel a less than ideal solution, unfortunately...
It is not very clear what it is that you want. It sounds like you need a desktop application, not a web-based.
> to create excel files from scratch
Actually there is not a real difference between creating excel files from scratch and using an empty excel file to start from. In both cases you'll probably need a limited number of templates. If you want users to design their excel totally freely, you need something like google docs.
> read these (and similar excel files)
Users can not "read" excel files on the server. They can download them.
> manipulate existing (either from this app, but also user created) excel files
Same issue: users can not manipulate excel files on the server through http. They can be downloaded, edited and uploaded again. For that you do not need anything special apart from download and upload of files.
> to create excel files from scratch
Actually there is not a real difference between creating excel files from scratch and using an empty excel file to start from. In both cases you'll probably need a limited number of templates. If you want users to design their excel totally freely, you need something like google docs.
> read these (and similar excel files)
Users can not "read" excel files on the server. They can download them.
> manipulate existing (either from this app, but also user created) excel files
Same issue: users can not manipulate excel files on the server through http. They can be downloaded, edited and uploaded again. For that you do not need anything special apart from download and upload of files.
ASKER
@emoreau we actually are using ExcelPackagePlus, the continuation of ExcelPackage
It can be found here: http://epplus.codeplex.com/
@sybe, I wasn't talking about users reading them, its actually code doing the reading, doing some manipulations, updating values, changing references and such and then writing the whole thing into a database. I'm pretty sure of what I need. And I'm very happy with the answer provided by emoreau.
It can be found here: http://epplus.codeplex.com/
@sybe, I wasn't talking about users reading them, its actually code doing the reading, doing some manipulations, updating values, changing references and such and then writing the whole thing into a database. I'm pretty sure of what I need. And I'm very happy with the answer provided by emoreau.
Here is an article to start a thought.
https://www.experts-exchange.com/Software/Office_Productivity/Office_Suites/MS_Office/Excel/A_3787-Understanding-Excel-File-Internals.html