I'm fairly new to programming with Interop.Excel and may lack the experience, but why is it such a pain to program with it? Casting objects everywhere, more or less no documentation on the methods (at least not in the code) and every method seems to return objects, so there is no way of telling what it actually does. Also, all arguments are objects to begin with.
Is there any good wrapper library out there that provides basic functionality (writing to cells, reading, creating sheets, deleting sheets, basic formatting and layouting) and does this in a good, clean and understandable (and by that I mean: well-documented) way?
PS: Working with C# and .NET-3.5
I'm using EPPlus and very happy with it. It's open source and free.
The owners offer support when ever it was required.
EPPlus on codeplex
Note that EPPlus doesn't support Excel 2003 format. .xlxs is supported while. xls is not.
Well this is quite pricey, but in my opinion worth the money if you are doing serious commercial work with excel. As well as being the fastest option, you also don't even have to have excel installed, anyone who has run excel on a server will understand why that is huge.
Http://www.spreadsheetgear.com
If you're having problems with using interop directly, you may want to try out OfficeWriter. It can do anything you've described above with Excel, and more. You can request a free trial. There's a fully documented api available at the documentation site.
DISCLAIMER: I'm one of the engineers who built the latest version.
Try ClosedXML, it wraps the OpenXML SDK to give a very intuitive way to create Excel files.
Related
A client wants to "Web-enable" a spreadsheet calculation -- the user to specify the values of certain cells, then show them the resulting values in other cells.
(They do NOT want to show the user a "spreadsheet-like" interface. This is not a UI question.)
They have a huge spreadsheet with lots of calculations over many, many sheets. But, in the end, only two things matter -- (1) you put numbers in a couple cells on one sheet, and (2) you get corresponding numbers off a couple cells in another sheet. The rest of it is a black box.
I want to present a UI to the user to enter the numbers they want, then I'd like to programatically open the Excel file, set the numbers, tell it to re-calc, and read the result out.
Is this possible/advisable? Is there a commercial component that makes this easier? Are their pitfalls I'm not considering?
(I know I can use Office Automation to do this, but I know it's not recommended to do that server-side, since it tries to run in the context of a user, etc.)
A lot of people are saying I need to recreate the formulas in code. However, this would be staggeringly complex.
It is possible, but not advisable (and officially unsupported).
You can interact with Excel through COM or the .NET Primary Interop Assemblies, but this is meant to be a client-side process.
On the server side, no display or desktop is available and any unexpected dialog boxes (for example) will make your web app hang – your app will behave flaky.
Also, attaching an Excel process to each request isn't exactly a low-resource approach.
Working out the black box and re-implementing it in a proper programming language is clearly the better (as in "more reliable and faster") option.
Related reading: KB257757: Considerations for server-side Automation of Office
You definitely don't want to be using interop on the server side, it's bad enough using it as a kludge on the client side.
I can see two options:
Figure out the spreadsheet logic. This may benefit you in the long term by making the business logic a known quantity, and in the short term you may find that there are actually bugs in the spreadsheet (I have encountered tons of monster spreadsheets used for years that turn out to have simple bugs in them - everyone just assumed the answers must be right)
Evaluate SpreadSheetGear.NET, which is basically a replacement for interop that does it all without Excel (it replicates a huge chunk of Excel's non-visual logic and IO in .NET)
Although this is certainly possible using ASP.NET, it's very inadvisable. It's un-scalable and prone to concurrency errors.
Your best bet is to analyze the spreadsheet calculations and duplicate them. Now, granted, your business is not going to like the time it takes to do this, but it will (presumably) give them a more usable system.
Alternatively, you can simply serve up the spreadsheet to users from your website, in which case you do almost nothing.
Edit: If your stakeholders really insist on using Excel server-side, I suggest you take a good hard look at Excel Services as #John Saunders suggests. It may not get you everything you want, but it'll get you quite a bit, and should solve some of the issues you'll end up with trying to do it server-side with ASP.NET.
That's not to say that it's a panacea; your mileage will certainly vary. And Sharepoint isn't exactly cheap to buy or maintain. In fact, short-term costs could easily be dwarfed by long-term costs if you go the Sharepoint route--but it might the best option to fit a requirement.
I still suggest you push back in favor of coding all of your logic in a separate .NET module. That way you can use it both server-side and client-side. Excel can easily pass calculations to a COM object, and you can very easily publish your .NET library as COM objects. In the end, you'd have a much more maintainable and usable architecture.
Neglecting the discussion whether it makes sense to manipulate an excel sheet on the server-side, one way to perform this would probably look like adopting the
Microsoft.Office.Interop.Excel.dll
Using this library, you can tell Excel to open a Spreadsheet, change and read the contents from .NET. I have used the library in a WinForm application, and I guess that it can also be used from ASP.NET.
Still, consider the concurrency problems already mentioned... However, if the sheet is accessed unfrequently, why not...
The simplest way to do this might be to:
Upload the Excel workbook to Google Docs -- this is very clean, in my experience
Use the Google Spreadsheets Data API to update the data and return the numbers.
Here's a link to get you started on this, if you want to go that direction:
http://code.google.com/apis/spreadsheets/overview.html
Let me be more adamant than others have been: do not use Excel server-side. It is intended to be used as a desktop application, meaning it is not intended to be used from random different threads, possibly multiple threads at a time. You're better off writing your own spreadsheet than trying to use Excel (or any other Office desktop product) form a server.
This is one of the reasons that Excel Services exists. A quick search on MSDN turned up this link: http://blogs.msdn.com/excel/archive/category/11361.aspx. That's a category list, so contains a list of blog posts on the subject. See also Microsoft.Office.Excel.Server.WebServices Namespace.
It sounds like you're talking that the user has the spreadsheet open on their local system, and you want a web site to manipulate that local spreadsheet?
If that's the case, you can't really do that. Even Office automation won't help, unless you want to require them to upload the sheet to the server and download a new altered version.
What you can do is create a web service to do the calculations and add some vba or vsto code to the Excel sheet to talk to that service.
Yes, I've already heard of http://www.codeproject.com/KB/audio-video/avifilewrapper.aspx
...but I just can't get it to work with ASP.NET
I've perused the source about a hundred times looking for anything that might suggest it's incompatible with .NET 3.5 or not going to work with my other frameworks. Everything seems Kosher.
Any ideas?
Thanks!
Do you know what exceptions are being thrown? The AviFileWrapper you mentioned I believe depends on libraries provided by the windows API, and those libraries might not be available in your server, especially for ASP applications.
If you need a solution badly enough, you might consider writing a simple library yourself. The AVI format might be simple enough to implement it yourself, given that you might not need sound or compression.
Here is some documentation I found.
www.alexander-noe.com/video/documentation/avi.pdf
Good luck.
I'm working on an application that generates a relatively large amount of Word output. Currently, we're using Word Interop services to do the document creation, but it's quite slow, especially in older (pre-2007) versions of Office. We'd like to speed up the generation.
I haven't done a lot of profiling yet, but I'm pretty confident that the problem is that we're making tons of COM calls. I'm hoping that profiling will yield a subset of calls that are slower than the others, but my gut tells me that it's probably a question of COM overhead (or Word Interop overhead), and not just a few slow calls.
Also, the product can generate HTML output, and that process (a) is very fast, and (b) uses pretty much the same codepaths, just with a different subclass for the HTML-specific pieces of functionality. So I'm pretty sure that our algorithm isn't fundamentally slow.
So... I'm looking for suggestions for alternate ways to accelerate the generation of Word files.
We can't just rename the generated HTML files to .doc, and we can't generate RTF instead -- in both cases, important formatting information get lost, and in the RTF case, inlined graphics don't work robustly.
One of the approaches we're evaluating is programmatically generating and opening a Word file (via interop) from a template that has a macro that knows how to consume a flat file and create the requisite output. We're interested in feedback about that approach, as well as any other ideas for speeding things up.
If you can afford it, I'd recommend Aspose.Words product. Very fast and Word does not need to be installed.
Also it's much easier to use then office interop.
Your macro approach is exactly how we sped up slow excel interop (using version 2003 i think).
We found (at least with excel) that much of the slowness was due to repeated individual calls via the interop. We started to bunch up commands (ie. format large ranges, and then change specific cells as required rather than formating each cell individually), and logically moved on to macros.
I think that the macro + template approach would happily translate.
Does anybody know of a good library for reading/modifying ms project files?
For me the COM interface also worked like a charm. There are a few traps, take care of the CultureInfo of your thread, set it to "en-US", there seems to be a similar issue as the LCID bug in Excel. Also call the methods of the COM from one single thread.
I had a look at your profile and could not judge if you know how to deal with COM under .NET or not. In our project just add a reference to the COM and then you should be able to use the methods. The MsProject API is quite low level (Database oriented) but proved to be quite reliable (that was not the case when I used Excel COM API).
I would go this way because then you do not depend on a 3rdparty library (only on MS) and you can do everything you could also do from within Macros. Other solutions might restrain you to what was implemented by the SDKs...
Does Aspose Tasks not do what you want ?
I know there is an example in the ILOG Gantt SDK that will load MS project files; I can't remember if it saves too, but it might help as a starter.
What about MS Project COM interface? I used it to make some web reports with it in the past...
The COM interface is a good bet as others have said. Microsoft have some more stuff here.
That said it might be easier to use MPXJ which purports to provide a robust and open API for manipulating various types of MS Project file.
You can use COM interface and you need to use a namespace"Microsoft.Office.Introp.MSProject"
I find it quite unbelieavble that the interop API is such a mess
A lot of methods have no comments on and seems to have been done very poorly
Has anyone else experienced the same and if so what library do you use to control Exel from C#?
The obvious practical problem with the VSTO/COM Interop technology is the overhead incurred when transitioning between worksheet and managed code. (And if you're trying to talk to Excel without the help of VSTO, stop doing so and save yourself some huge headaches). I thought VSTO did a pretty good job of providing a close analog of the Excel object model in the managed environment - certainly I didn't need to spend much time trying to understand much more about .NET Interop.
For longer-running automation activities the overhead's not so much of a problem, similar concerns to VBA automation apply: reduce calls across the interface as far as possible to get best performance.
For smaller, faster worksheet function-type work (the sort of thing where we might write an XLL, say) that overhead can be a killer. ExcelDNA seems to be a great way into delivering managed code through the XLL model - and the price is right.
SpreadsheetGear for .NET is an Excel compatible spreadsheet component for .NET. It will not enable you to control Excel, but it will give you an Excel compatible spreadsheet engine for ASP.NET / WinForms / etc... that can create, read, modify, view, edit, format, calculate, print and write Excel workbooks and charts from .NET. Since SpreadsheetGear is 100% safe managed code, there is no per-call performance penalty like you get with Excel.
The SpreadsheetGear API is very similar to Excel's API - except for the fact that many APIs are more strongly typed so they tend to be easier to use from C# than Excel's API.
You can see a feature list here, live ASP.NET reporting / charting / dashboard / calculation samples for VB and C# here and download the free trial here.
Disclaimer: I own SpreadsheetGear LLC