If you are making minor changes to existing Excel files then Matt's approach is reasonable and sensible. Create a template/baseline spreadsheet and save it as a .xlsx file and then open, modify and save that using OOXML and send that to your clients.
If you are making quite significant changes and effectively *creating* the document rather than updating fields etc. then the learning curve of OOXML is going to be pretty steep and the nature of working at that lower level of abstraction means you would in my opinion be better off using a 3rd party library to do this. As others have mentioned you can use Aspose, we use Syncfusion. Aspose and Syncfusion expose a higher-level object model and are easier to work with than OOXML but unlike OOXML they aren't free. That said, after evaluating all of the previously discussed options (and more) for MS Word and MS Excel document support we're very happy with our decision to go with Syncfusion and have received truly terrific support from them. Regards, Ben ________________________________ From: [email protected] [mailto:[email protected]] On Behalf Of Matt Siebert Sent: Monday, 21 February 2011 4:04 PM To: [email protected]; ozDotNet Subject: Re: Excel in .NET (C# or VB) Another option is the OOXML SDK (see openxmldeveloper.org<http://www.openxmldeveloper.org/> and Microsoft's Open XML Developer Center<http://msdn.microsoft.com/en-us/office/bb265236>). I'm using it for similar functionality with Word documents. It also supports Excel but I haven't tried that yet. It has no dependencies on Office or it's PIAs, but it is limited to the Open XML formats (i.e. 2007 and above) and may require a bit more effort to understand the file structure, etc. In my case, since I need to be really flexible with the exact layout of the file, I'm actually embedding an XML document containing my data into the Word document and binding Content Controls to this so later on it's really simple to just read the info out of the XML part. Unfortunately Content Controls aren't available in Excel (at least not in 2007), but if you're scenario is similar to mine and you're not specifically tied to Excel then this might be useful. On Mon, Feb 21, 2011 at 5:49 PM, <[email protected]<mailto:[email protected]>> wrote: Hi, Oledb will give you loads of problems, the data types in the spreadsheet are defined by the best match of the first 5 rows or so. Really not good. If you were just reading the file then nexcel is my preferred way and it works on asp.net<http://asp.net> with no hassle. But as you are updating there isn't a simple solution at all. Davy "When all you have is a hammer, every problem looks like a nail." I feel much the same way about xml -----Original Message----- From: "etmilis" <[email protected]<mailto:[email protected]>> Sender: [email protected]<mailto:[email protected]> Date: Mon, 21 Feb 2011 16:02:27 To: 'ozDotNet'<[email protected]<mailto:[email protected]>> Reply-To: ozDotNet <[email protected]<mailto:[email protected]>> Subject: RE: Excel in .NET (C# or VB) Thanks Craig and Arjang, Concern noted. We are asked to automate/integrate files (i.e. invoice, inventory, etc.) received from customer (in Excel via email) with internal system and need to update some databases/tables too. We will also need to send back the updated Excel file (original file + added/updated columns) to the customers. It looks like there are 2 ways to do it, using the Excel object model or the OLEDB, though I am leaning more to the object model. So, is it a good design if we create a service or a .net assembly with scheduled job to it? The frequency is pretty low, a few times in a day during business hours only. Cheers, Etmilis -----Original Message----- From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Arjang Assadi Sent: Monday, 21 February 2011 3:37 PM To: ozDotNet Subject: Re: Excel in .NET (C# or VB) Hi Etmilis, as Craig said ( also from personal experience ), do not try reading and writing excel files on the server, there is no end to problems that need to be solved. What is the original problem that you think it requires reading and writing to Excel Files? Regards Arjang On 21 February 2011 15:10, etmilis <[email protected]<mailto:[email protected]>> wrote: > Hi Everyone, > > In the current DNA with .NET, is it much easier now to deal with EXCEL? > Is COM still in the game? > > What I am after is reading from and writing to an EXCEL file(s). > Also will it be possible to do it without installing EXCEL at all, for > example just referencing some of the EXCEL assemblies??? > > Thanks and Regards, > Etmilis > > This email is intended for the named recipient only. The information it contains may be confidential or commercially sensitive. If you are not the intended recipient you must not reproduce or distribute any part of this email, disclose its contents to any other party, or take any action in reliance on it. If you have received this email in error, please contact the sender immediately and delete the message from your computer.
