I have a windows form that works fine on my machine, I have a reference to the Microsoft.Interop Assembly for Excel 2007. Certain machines will have both Excel 2000 and Excel 2007 installed, and if Excel 2007 is not set as the "Default" version of Excel the windows form will throw an error and not work. Is their a way I can "package" my windows form to allow it to run error free on a machine with both 2000 and 2007 installed?
You're currently using Early Binding to access Excel. This is where you embed your reference to the interop in the project before compiling.
Advantages
Version of Excel is known to the compiler
Faster execution as we know that the methods exist and where they are
Allows us to use intellisense to check arguments are correct and that return types are correct
Disadvantages
Supports only the embedded versions of Excel
You need to take a look at Late Binding. This is where the interop is not included in the project at all and instead is bound later through reflection. You basically trade off all the advantages above for being able to support multiple versions of Excel.
There's lots of guides online that talk about how to do it.
How to use use late binding to get excel instance?
C# : Late Binding Excel Interop Tutorial
Word Automation using Late binding - Usage of dynamic Keyword
My two cents
I must echo Hans comment, this is a bad idea. Trying to support a 15 year old version of Excel is a recipe for massive headaches and I think you'll quickly look to avoid doing this.
Unless you're absolutely set on doing it this way, maybe you can look at a third party library like EPPlus. Or if you only need to read the sheet, do it some alternate way like ODBC and avoid this altogether.
Related
I am searching a C# way to delete (empty) Excel-rows in a worksheet without using the Microsoft.Office.Interop.Excel namespace.
Found many examples with the Interop namespace like C# and excel deleting rows . But is there a way to do it without third-party-tools - only with the .NET?
Thank you for your help!
The options for working with Excel files relying only on standard .NET Framework namespaces is limited. Two possibilities come to mind. The first is "simplest", but only applicable if your main interest is in working with the content as a database. The second allows you to do pretty much "anything" with the Excel workbook, but the learning curve will be steep.
Both of these approaches are suited for working in a server environment (unlike those that require presence of the Excel application) and do not require any licenses.
You can use an OLE DB connection (ACE OLE DB provider) to communicate with the contents of an Excel workbook. It allows connecting to individual worksheets as well as named ranges. Basic SQL functionality is supported.
The file format of Excel 2007 and later versions is Office Open XML (OOXML). These files are "zip packages" containing the files (xml for the most part) that make up a workbook. So any standard tools that can work with Zip packages and XML can be used to open up an Excel workbook, edit the content, then close the workbook back up. In the .NET Framework, these would be the System.IO.Packaging (in WindowsBase.dll, usually needs to be referenced specifically) and System.XML namespaces.
The documentation for the file formats is the ECMA-376 standard (http://www.ecma-international.org/publications/standards/Ecma-376.htm). A useful on-line resource is openxmldeveloper.org.
Note that Microsoft also provides the Open XML SDK, a free download which can be distributed license-free with your solution. The Open XML SDK reduces the "learning curve" as it reduces the amount of knowledge you need about the OOXML file formats. I mention this for the sake of completeness, because I know how challenging trying to work directly with the file format is. Also, since the DLL is freely distributable and can be copied as part of your solution it might meet your requirements.
This stackoverflow post may help - it discusses some libraries that can manipulate excel without needing Office installed.
The question regards VB.NET but I believe the options discussed would work with C# too...
How to process excel file in vb.net without office installed
We have a number of .xla/.xlam Excel Addins and the time has come to migrate to something easier to version control and maintain.
I'd like to write in C# if possible and the Addins will need to do the following sorts of things:-
Provide User Defined Functions to Excel
Create and manipulate named ranges in the Excel sheet
Pull data from external sources and populate cells in the Excel sheet
Currently all this is possible and simple to do with a .xlam what are the pros/cons of moving to VSTO or creating a C# Addin (I notice VS2010 has a New Project option of creating an Excel 2007 Addin).
Are there any good sources of documentation?
Thanks
Dave
I would recommend you seriously look at Excel DNA (Free) or Addin Express (chargeable). Both provide .Net functions via the .XLL interface together with .COM to .NET interface if you need it.
Performance of both of these makes VSTO look like molasses, and installation is realtively simple.
For easy creation of performing UDFs XLDNA is VERY hard to beat.
Has to be free.
Has to support all versions of Excel files.
Has to have C# .NET API.
I need to do all of the specified actions (reading/creating/updating).
Has anyone used any library l this kind sucessfully
Update:
I read a lot of bad things about Ole DB, and Interop is not an option since this is a web application running on a server.
Try to use OleDB Reading Excel files from C#
From a previous answer on a different question:
You might consider using the Excel object model and COM interop to read the data from the Excel file into your application. Granted, this includes a dependency on Excel being installed, but it is a possibility. This article has some great code for getting started with reading Excel files in this way.
A better way might be to use a library that doesn't have a dependency on Excel being installed on the local system. This answer suggests using the Excel Data Reader library, available on CodePlex.
Like I pointed out in my other answer, there are paid third-party libraries that will likely do exactly what you are looking for. I understand you want something that is free, but in my experience with free Excel libraries, you tend to need to do a good bit of extra work to get it to play the right way.
I'm a big fan of Aspose Cells. It does all you want but it isn't free. I don't know any other products that can fit all your needs (All Excel Versions, C# Api, Read/Write, etc)
I'm looking for any available free Excel "helper" classes that are written for .net (doesn't have to be C#).
I'd like to evaluate what others consider to be useful and generic static (and non static) helper methods.
Can be targeted at VSTO or regular Office automation, although that probably doesn't matter.
I guess I should also point out that this question is NOT asking for "what are good alternatives (or free alternatives) to using Excel object model automation. I don't really want links to SS gear, etc, although they are all great products that's not the purpose of the question.
In case I wasn't clear enough in the previous paragraph: I don't want answers that state - use this free (or not free) 3rd party component, instead of Excel object model code.
So basically what i was asking for was user developed C# code libraries that contain VSTO, Office or Excel helper functions such as static methods for working with menus, ribbons, ranges, workbooks, documents, xml (such as the ones otaku mentioned)...
VSTO Power Tools is a good set of utilities to work with Excel:
http://msdn.microsoft.com/en-us/magazine/dd263100.aspx
ExcelDNA is a very cool project. It provides a lightweight way to consume .NET code from Excel, with a deployment model which is much easier than VSTO. I found it an interesting alternative to VSTO if you want to write UDF in .NET for instance.
In terms of Office automation for Excel, there are some good PowerShell Open XML cmdlets that can be used for PS or ported to C# at Announcing the Release of PowerTools for Open XML V1.1. Eric White's blog, where this link is, has recently done an more in depth look at Excel automation using Open XML, like Table Markup in Open XML SpreadsheetML. Note about Open XML - although it is the preferred method by many, you don't actually have to use the Open XML SDK - you can just use System.IO.Packaging to gain access to Excel 2007/2010 files.
Also, often overlooked, but the Excel snippets available for VSTO, Open XML and Interop development are great. 1, 2, 3
Also, check out the Excel samples for VB # http://msdn.microsoft.com/en-us/library/8x19fbw1(v=VS.90).aspx. These come installed with VS when you also choose VB as a language during the install.
Update: Just discovered the All-In-One Code Framework (Office) which has a lot of great Excel helper classes. You can find it on: http://1code.codeplex.com/releases/view/51868.
For VSTO projects:
http://www.add-in-express.com/
Non-VSTO, non-automation:
http://www.html-to-pdf.net/excel-library.aspx
Note: neither of these libraries are free.
There's one called FileHelpers which enables you to save Excel data as CSV and the FileHelpers library can easily parse the information and so on, sure it may not be fully blown Excel automation, but it is a good headway to parsing. If you're talking about being able to deal with Excel in a native binary fashion, then this article from CodeProject might help, also here, is BIFF parser that understand the underlying excel data storage, and also here on CodeProject.
With .net 4.0 dynamic keyword writing Excel automation easy as hell.
If you want intellisense you can easily write c# wrapper on top of dynamic calls.
UPDATE
We are working with Excel automation since 2001 (developing financial addins).From Excel 2000 up to 2010.
And all we know that standard interop simply does not work when your code should work with all versions and service packs of Office.
We had beaten many times by custom interop libraries, VSTO versions, etc. After a year we found a only one solution that works - call all automation via late bound calls (reflection). i.e. (''notepad code'') Type.GetTypeFromProgId('Excel.Application').GetMethod('Visible').Invoke(....).
But code was very big and ugly, then we simply wrap that ugly code with Object Model copied from Excel 1:1. When we need new method we add it to our Excel Object model and call excel automation via late bound call.
With new dynamic keyword it is possible to live without wrapper especially with Resharper's dynamic support.
I prefer this one:
Excel Package on CodePlex
it uses the Open XML, so no need for an office install on the computer (may or may not factor in), but I found it very easy to use and set up.
I really like NPOI for 2003/2007 formats
http://npoi.codeplex.com/
Totally standalone and easy to use
What is the best way to export objet to excel file in C# (.net framework 3.5)?
Thanks in advance!
If it's tabular data, you could generate HTML tables and let Excel open it up intuitively. Otherwise I'd recommend COM Interop.
I've used EPPlus to generate xlsx files (basically reports - SQL Reporting Services 2008 R2 still doesn't support it natively, just the older xls).
I've heard good things about NPOI, which is a .NET port of the Apache POI project
If you want to do it 'natively' and interop with a real instance of Excel, you can use the classes in Excel's Primary Interop Assembly - look in the microsoft.office.interop.excel namespace
A lot depends on what kind of objects you have already and what you want your intended output to be - if you can specify more of that, we can give a more specific answer.
In the past I've used the clipboard to save objects to multiple formats that can then be pasted into different applications including Excel or Word, tyring to find an example online I stumble across this:
http://support.microsoft.com/kb/306023
Looks Good!