I'm gathering that if we can read external styles.xml file and apply to our workbook using OpenXML would be more efficiently than styling in our code. I have done a lot of research but still not get any solution.
Please tell me if it possible or not and give me some resources (if any) about this.
Yes, it's possible to modify styles.xml directly but that doesn't mean it's a good idea. I've seen a few people try to work directly with the styles but I have yet to see it turn out well -- and these are people with many years of experience with XML, coding and Excel is general, who figured they had exhausted usability of Excel's built-in features and figured they could do a better job at it than Microsoft can.
If you are confident that you can build a stylesheet more appropriate for your project (than what Excel's developer provided) you'll be able to find full specifications by researching ISO 29500-1.
Overview from Wikipedia
ISO/IEC 29500-1:2016 (7000+ pages)
Generating Excel 2010 Workbooks by using the Open XML SDK 2.0
How to: Manipulate Office Open XML Formats Documents
How to Diagnose Excel file corruption and Repair Workbooks
[Solved] File corrupt and therefore cannot be repaired
*I'll admit I'm very curious about how Excel's stylesheet is no longer suitable for your organization's requirements!
Related
I am creating an xls document using Microsoft.Office.Interop.Excel but it's not working in IIS7.
I am getting the error message below
Microsoft Office Excel cannot open or save any more documents because
there is not enough available memory or disk space. • To make more
memory available, close workbooks or programs you no longer need. • To
free disk space, delete files you no longer need from the disk you are
saving to.
Is there any other free tool or option that we can use to create xls in web server?
First of all it is not a good idea to use office interop API on a server as described in this link.
For free tools you could look at ExcelLibrary and Epplus that seems to be popular but I never used it. The other option would be to use the OOXML SDK 2.5. With this you can create only Xlsx files and has a learning curve.
For more info have look a this topic that, although it is closed, contains probably all the info you need.
Currently our application exporting large data to office 2003 xml spreadsheet format in server.
The user can download the xml file.The file can be easily opened in office 03 and 07 correctly.
I want to know whether it is possible to create xls and xlsx format from this xml file in server and serve them to user?
[The server doesn't have office and neither will be.So interop is useless in this case.]
====== EDIT=====
Can't use third party solutions... :(
With your XML file, you could easily use XSLT to transform your XML into CSV. However, if you really need to export in native Excel spreadsheet types, it's probably a good idea to use a component.
Something we've used in the past, that I'd recommend, is Aspose.Cells – we've used this to generate Excel spreadsheets where plain CSV output wouldn't suffice (are you sure it won't suffice in your case - XSLT will make short work of that).
Whilst it's not free, it saves having to install Office on the server (and avoid using Office Automation etc.) and has very good support.
Edited following comments:
If you can't use third party components, if you can't install Office on the server, and you can't use interop, then – unless you want to get comfortable and read the Excel Binary File Format (.xls) Structure Specification as provided by Microsoft – the answer is a very short one: no.
If I understand your question corretly, you are not just serving 'pure' XML, but SpreadsheetML that is interpreted by Excel just as an ordinary Excel-file in binary format. So your users already have a very nice solution. How do are you creating those files? I use an XSLT to transform my XML-data to SpreadsheetML that is just a specific XML-format. In that way I can do anything that is possible in Excel (formattings, formulas etc.). It yould be much more than just transforming XML to CSV.
Why do you want to change this? I can see that the resulting XML-Excel file usually is huge, is that the reason?
Now, since Excel 2007 format (xlsx) is basically a zip-archive of some XML-files describing the structure and the data of the file -- just rename the file extension name of any xlsx to zip and inspect after extracting -- you might be able to adapt your existing solution, i.e. instead of creating one SpreadsheetML-(XML)File create several and pack/zip them one the server. I assume your normal server installation should have the necessary tools.
BUT - this solution is difficult to maintain (as you might know wiht you current solution -- if I am at all right) and changes in the XSLT to add new functionality requires quite a bit of knowledge. So again I as well can recommend Aspose.Cells, even some knowledgeable users might be able to change simple formats.
HTH
Andreas
If you don't have office 2003 *or later) DLLs referenced to the project, I'm afraid you can't read that Office XML data in your program directly, unless of course you can manually parse the whole XML by studying its format.
You can use Open XML SDK to create or read xlsx files.
http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=5124
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.
How can I 'read' an excel 2003 document stored as a sharepoint spfile? I can retrieve the document from the library with no problems using the SPFile.OpenBinary() and then putting that into a MemoryStream.
The original idea was to use OpenXML to interrogate the document (which will take this object type as a constructor), but the Excel version (2003) prohibits this.
Just to cloud the issue further, there is no guarantee that I will have any Excel version on the host machine, so possibly won't be able to use the interop assemblies either.
Suggestions or solutions will be gratefully received.
When I say read, I mean pull data from named ranges, cell references etc. All of the open source libraries I have found (Exceldatareader, NOPI, OpenXML) have some limitation or another that prohibits their use. e.g. can't load macro enabled sheets
The excel document is loaded into a sharepoint library which exposes this list as a collection of SPFile(s). These files can be read into a MemoryStream simply enough, but most of the libraries I have tried require a filestream constructor, which means writing to the filesystem on the application server
I've not tried SpreadsheetGear, but if there's no footprint on the filesystem, then I'll take a look for sure, but this is not an option on this project. I'll update this thread with my findings...
I'm reduced to using the PIA's. Dirty, dirty, dirty.
SpreadsheetGear for .NET can open a xls and xlsx workbooks from a memory stream with SpreadsheetGear.Factory.GetWorkbookSet().Workbooks.OpenFromStream(System.IO.Stream) and also has the ability to open directly from a byte array with OpenFromMemory(byte[]). Once opened, SpreadheetGear has a comprehensive API, calculation engine, rendering engine and more.
You can see live samples here and download the free trial here.
Disclaimer: I own SpreadsheetGear LLC
I've found this [library] (http://exceldatareader.codeplex.com/) on codeplex which seems to be able to read any Excel version. There might be a lot more on the web
When you say read what exactly do you mean? There seems to be some great debate amongst developers as to what the term's definition is. Either way it shouldn't really matter if Excel is on their system or not, on account of I am only pretty sure that if the person wanted to view the file any way they would need at the very least a reader. So that being said I believe your fear is a moot point and that using a MemoryStream should suffice.
I'm confused as hell with all the bazillion ways to read/write/create excel files. VSTO, OLEDB, etc, but they all seem to have the requirement that office must be installed.
Here is my situation: I need to develop an app which will take an excel file as input, do some calculations and create a new excel file which will basically be a modification of the first excel file. All with the constraint that the machine that runs this may not have office installed. (Don't ask why...)
I need to support all excel formats. The only saving grace is that the formats spreadsheets themselves are really simple. Just a bunch of columns and values, nothing fancy. And unfortunately no CSV as the end user might not even know what a CSV file is.
write your excel in HTML table format:
<html>
<body>
<table>
<tr>
<td style="background-color:#acc3ff">Cell1</td>
<td style="font-weight:bold">Cell2</td>
</tr>
</table>
</body>
</html>
and give your file an xls extension. Excel will convert it automatically
Without Office installed you'll need something designed to understand the Excel binary file format (unless you only want to open Office 2007 .xlsx files).
The best I've found (and that I use) is SpreadsheetGear, which in addition to being .NET native, is much faster and more stable then the COM/OLE solutions (which I've used in the past)
read and write csv files instead. Excel reads them just fine and they're easier to use. If you need to work against .xls files then try having support for OpenOffice as well as Excel. OpenOffice can read and write excel files.
Did you consider way number bazillion and one: using the Open XML SDK? You can retain styles and tweak it to your liking. Anything you can do in an actual file is possible to achieve programatically. The SDK comes with a tool called Document Reflector that shows the underlying XML and even shows LINQ statements that can be used to generate them. That is key to playing around with it, seeing how the changes are made, then recreating that in code.
The only caveat is this will work for the new XML based formats (*.xlsx) not the older versions. There's a slight learning curve but more material is making its way on blogs and other sites.
If cost is not an issue, I'd suggest looking in Aspose's Excel product. I use their Word product and I've been satisfied.
Aspose.Cells
Excel XLSX files "just" XML files - more precisely ZIP files containing several XML files. Just rename a Excel file Test.xslx to Test.zip and open it with your favourit ZIP program. XML schemas are, afaik, standardized and availiable. But I think it might not be that easy to manipulate them only using primitive XML processiing tools and frameworks.
Excel files are in a proprietary format so (afaik) you're not going to be able to do this without having the office interop available. Some third party tools exist (which presumably licence the format from MS?) but I've not used them myself to comment on their usefulness.
I assume that you can't control the base file format, i.e. simple CSV or XML formats aren't going to be possible?
I used to use a very nice library called CarlosAg, which uses Excel XML format. It was great (and Excel recognizes the format), and also incredibly fast. Check it out here.
Oh, as a side note, we used to use this for the very same reason you need it. The servers that generated these files were not able to have Excel installed.
If you cannot work with CSV files as per #RHicke's suggestion, and assuming you are working on a web app, since a desktop app would be guaranteed to have XL installed as per requirements.
I'd say, create your processing app as a webservice, and build an XL addin which will interact with your webservice directly from XL.
For XLSX files, look at using http://www.codeplex.com/ExcelPackage. Otherwise, some paid 3rd party solutions are out there, like the one David suggested.
I can understand the requirement of not having office installed on a server machine.
There are many libraries like aspose being available, some of them requiring license though.
If you are targeting MS Excel formats, then a native, Interoperability library, ACE OLEDB data provider, from Microsoft is available which you can install on a machine and start reading, writing programmatically. You need to define a connection string and commands as per you needs. (Ref: This article #yoursandmyideas)talks about using this library along with setup and troubleshooting information.