Has anybody used/evaluated both of these libraries and can tell me the difference?
Otherwise has anyone here used SmartXLS for reading/creating/updating excel files and can tell me his experience?
The later is considerably cheaper than the former.
I have used SmartXLS for quite some projects for my clients and it works fine for me. I use it to create Excel files from scratch, but also to update existing Excel files (XML, XLS and XLSX). I only have textual information in my sheets. No formulas, images, etc.
In the past, I have encountered a bug once. The SmartXLS team fixed it within one hour after I reported it. Recently, for another project I needed an extension to their library (save as XML). Even despite the fact that I do not have a support contract, they implemented it for me within two days. I wanted to share that they have good customer support, which is for me one of the most important aspects when I purchase a 3rd party library. Disclaimer: I do not work for SmartXLS and am not sponsored.
I have used SmartXLS is several projects to create spreadsheets from scratch, or to use one as template. Sofar everything I wanted it to do, it did. Disclaimer, I neither work for or am sponsored by SmartXLS' developers.
Related
This question already has an answer here:
Use Office Interop on ASP.net MVC6 website
(1 answer)
Closed 6 years ago.
I want to generate excel file. That's why I am using Microsoft. Interop. excels library and my work has been done. But right now someone says Microsoft. Interop. excels library is not a good approach for web based projects. It is good for desktop based project. Is it true. If true, so why and what's the issue that approach not suitable for the web. And which is the better approach for generate excel file on web based project.
Actually I have some experience with working with Excel files in both web and windows environments.
My answer to you is that it heavily depends:
Microsoft.Interop.Excel(Let's call it MIE) is cross calling Excel libraries itself to do it's job therefore it's more reliable in case of future versions and better upgradable. But it's not well formatted, there will be no intellisense and most important one you require Excel installed on the running machine.
So base on these info you need to answer these questions:
1- Are you gonna distribute your code or you are going to deploy it?
2- Do you have access to server or no?
3- Is it to create Excel or to read it or both?
4- Is it a project for a long run or a short lifetime one?
1) If you are going to distribute your code find a third party tool. Because if you use MIE you need to tell your customer to install Excel on their machine (which they might be unable to do because of the question 2) and also your code might break because of it's communication issues with MIE.
2) If you don't have access to server (i.e. a hosting deployment environment or your server is managed by your company), you can't install excel on it so let's select a third party tool, compiled in your code.
3) If you want to read excel and you answered the previous questions go for MIE it's a must since most third party tools aren't really good and reliable for opening files. They are mostly able to create ones. Unless you want to create files then you want to use the same files later. Usually third party tools are great in opening files created themselves.
4) If it's gonna work a long time it's better to use MIE because it's essentially better to maintain. Microsoft uses this MIE in their products like Dynamics CRM so they need to keep it backward compatible.
I hope this helps you and it's all based on my own experiences. I'm open to correct myself if I'm wrong so help me in the comments.
I've accessed excel files using desktop applications using OleDbReader, interop, and the latest (and my fav), ling-to-sql. However, this time I need to do so from a Web application using asp.net with C# code behind.
I don't need to create excel files, only read them. Is it possible to do this with a .xls(x), or should I be shooting for .csv?
Looks like they have lots of different solutions posted here: Reading Excel files from C#
Looks like a combination of people recommending ADO.NET as long as the Excel file is pretty straightforward (since there might be "quirks" depending on what type of data you are storing) or different 3rd party tools.
I'd recommend going with CSV. We have a lot of difficulty working with xls files on web servers. Mainly because of Microsoft's restrictive licensing. You'd have to have an Excel license for everyone who'd be accessing the file.. well maybe. That's how it is for us anyway. It might be different under other circumstances. Anyhow, it's not really practical.
I been searching for the past while for an application which will port a excel workbook to c# code the closest I found was spreadsheetgear but its not of great use, I've slowly come to the conclusion that I will have to write the code myself.
Does anyone know of any freeware command line tool or opensource project which will accomplish this?
The reason that I wish to do this is simple, Excel\VBA is terribly slow even when optimized
some computations can take days, but due to is simplistic use, excel is a standard tool for model building. We have a java port which is dramatically quicker, but we are constantly updating the model and as such each minor change must be checked and recheck which takes time.
My aim is this, have a tool which will take an excel file as input parse all the formulas and values and output c# equivalent code, the few subroutines will be manually ported. A graphical design will then be manually created which will wrap around this generated code.
I have the generally code structure laid out in my mind, how I will accomplish this aswell as the libraries that I will use for reading excel files. But as I'm quite certain this is not an original problem, nor do I think the solution is overly difficult I would presume that there is some public project?
If you want to read Excel files from C# the VSTO Developer Center may be a good start.
As a side note, I think if you are trying to port general Excel applications to C# automatically you have quite a big project. For a small subset of applications where the Excel sheets follow a similar pattern it might be reasonable to do.
But to really benefit from porting Excel applications to C# you will have to rewrite them to use appropriate data structures in C#.
I got the requirement to output some reports as Excel 2002 spreadsheets.
Normally a job for reporting services - however - that's "not great IMO" and I hate it so for this project I used ExtJs - which doesn't do any excel output - not really - but does do the UI really, really well.
The reports will need to have outlining, grouping summaries and all sorts of formatting not available if I use the plain XML formatting. This is the one thing Reporting services does do really well. Gutted.
So... Does anyone have any suggestions for alternatives to reporting services and definitely not installing Office on the server? Crystal reports are just as "not great IMO" as RS so not that either :)
I have looked at aspose et al but they're a bit expensive and I'd like to find something open-source, if possible - such as perhaps using open office -, if I can find a way of using OOo on the server without actually installing it.
Any ideas?
If your reports are not very large perhaps you can get away using the free version of Gembox Spreadsheed?
The Perl module Spreadsheet::WriteExcel works very well at generating reports in Excel format.
SpreadsheetGear for .NET can do it and requires only ASP.NET 2.0 on the server (no reliance on Excel or any other libraries).
You can see live ASP.NET (VB and C#) Excel Reporting samples here.
If performance is important at all, I would suggest running your own performance tests with your actual data and formatting as you compare your options.
Disclaimer: I own SpreadsheetGear LLC
I ended up going the OpenXml SDK route - which is a bit of a PITA in some situs but good in others - once you get the hang of it...
The answer to this depends on budget, time and whether r not you're allowed to install coms on the server -
for us all of the above were negative,
we needed the follwing:
export of generic data
grouping of certain columns
sumarisation of certain columns
template based output
sql server reporting services offered all of this if - and only if you adhered to their rules.
what we have now is near as damn it ad-hoc reporting - using extjs for the ui, nhib for the domain castle windsor for the binding, and ooxml sdk 2.0 for the export.
if you need the code for the ulti level grouping excel output give me a shout :)
w://
I am working on (right now) a windows service that does Excel and PDF generation and merging on the server, unattended, using the SyncFusion XlsIO components.
So far this has been effective. The only limitation I have run into is the ability to read some 'legacy' html/xml based Excel formats.
Not Open Source, or free unfortunately but it is a workable option.
We have an Excel 2002/XP based application that interacts with SQL 2000/5 to process fairly complex actuarial calculations. The application performs its function well, but it's difficult to manage.
We're trying to create a "controller" application or service that can manage and monitor these various instances of Excel (start/stop/process commands etc) but it's a bit of an InterOp nightmare unfortunately.
Does anyone have a good (i.e. working) example of doing something like this in VB.Net or C#?
Don't do it!
We tried for weeks to get something like that to work and it simply does not behave as advertised. Don't even start - give up immediately!
The only options that you really have is a heavy server-side MOSS based implementation - Excel (Web) services (they call it something like that). Windows based COM Excel interop is pretty much dead and will be replaced by MOSS.
The other option is to use SpreadsheetGear. It is actually a fantastic product
It is lightlingly fast
The engine is separate from the UI so you can use it to do Excel stuff server side (with no office installed)
Fairly cheap
Has an API similar to the existing Excel COM api so moving code across is relatively easy
It all depends on the formulas that you need in your spreadsheet. Have a look at the formula list for Spreadsheet Gear and if there is a match go for it.
Interop works fine except that you always end up with references to Excel objects that aren't released, so Excel instances won't close. The following KB article explains why:
http://support.microsoft.com/default.aspx/kb/317109/EN-US/
You can avoid the problem if you have very carefully written code for a limited set of Interop scenarios. But in the general case it's very difficult to get it working reliably.
You might want to take a look at this product: http://www.spreadsheetgear.com/products/spreadsheetgear.net.aspx
It's all managed code and direct .NET libraries. No InterOp headaches. I haven't used it myself, but I've heard very good things from people in the finance world.
We have written a service that controls a single instance of Excel 2003. We never managed to get Excel instances to close cleanly, so we start one instance when the service is first accessed and use only that, serializing client requests.