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#.
Related
I've recently been given a task to populate a Word 2007 file with information retrieved from Rhapsody using the Rhapsody API. I'm not super familiar with Rhapsody, but I'll learn. I'm having difficulty tracking down a good way to write a program that can write to a formatted (read: tables) word document. I'm best at java, but I'm capable of using C#, C++, or VB. The problem seems to be that all options for java require the use of 3rd party libraries, and I'm not sure if I'm comfortable using them. All of the languages available in the Microsoft Visual Studio seem to have options for writing out to a Word Document, but I can't seem to figure them out. What would be my simplest option in attempting to tackle this task?
Aspose words does a really good job integrating C# with MS word.
http://www.aspose.com/categories/.net-components/aspose.words-for-.net/default.aspx
I am not sure if you already tried all features of Rhapsody Reporter Plus (in built) and Rational Publishing Engine (additional licenses might be required). With them you can produce html, pdf, word documents...
If this is not your use case and you need your own plug ins in java, we have good experiences with Apache POI, which I could recommend.
I don't understand why you might have issues using 3rd party libraries, when you write everything by yourself you might end doing such a similar library, expending of course "some" time and "some" headaches until having it ready...
Background: I'm trying to make a decision on whether to go down the road of automating Excel using C# via Interop. I'm certainly not a VBA guy and for numerous reasons, I'd prefer not to go down that road. I don't know much about other options, and I'm really not looking to buy anything.
Performance is massively important.
I've tried to find references on using Interop to automate Excel and it seems rather sparse. Some of the better stuff is dated and other references just don't cover a lot of the material. Many folks cite the fact that a lot of the existing material spends time focusing on differences in version of MS Office. I'm also wondering whether the improvements that have been claimed with moving to .NET 4 are material.
Edit: The crux of what I'm trying to accomplish is complete automation of fairly involved and intricate formatting as well as some pretty heavy analysis (linear regression). I need to chart data once analyzed/calculated and the chart formatting is really important because the MBA's I work with say it is. I guess all of this is possible via VBA but I don't know for sure because I'm not a VBA guy. Think macro type stuff with the app hidden so it's running as a background process. Performance is critical (one of the reasons I question COM's appropriateness). VBA may even be off the table due to its performance considerations.
Now, for the question.
The best way I can ask this succinctly is: is there a laundry list of stuff you can't do with Interop in Excel that you'd like to be able to do? How have you gotten around it in your development experiences?
If there really isn't anything you can't do with Interop (see comments below) and it's the best fit for what I'm intending to do, what is the best way to go about learning to use it given that COM and the Excel object model can be a fairly intimidating undertaking. Are there really good references out there?
If there's a better way for me to go about the above, can you tell me about it? Excel DNA was mentioned but I can't see it being much more helpful than allowing the creation of user-defined C# functions that can get to a backend server app or database somewhere.
There is no correct answer to your questions: it all depends on the details and the background.
Interop performance when interacting with the Excel object model (get/put data formatting charts etc) will always be relatively slow because of the additional layers on top of COM.
.Net calculation speed can be faster than VBA calculation speed particularly with poorly written VBA code.
The .NET framework is much more powerful and complex than the VBA framework.
The Excel object model is large and complex. The VBA macro recorder can be helpful with this but produces apalling code.
The XLL interface is faster than COM but exposes less of the Excel object model. Given your description my guess is that you would get better performance, ease of learning and use with VBA rather than than .NET because it seems likely that the majority of time will be spent interacting with the object model rather than doing linear regression calculations (which are not IMHO particularly CPU intensive).But of course other considerations might make you prefer .NET
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.
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.
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.