Develop Reference

Is NPOI better than Office Interop in C# for automation using Selenium WebDriver

I am using C# and Selenium WebDriver for automating our web application. The test data will be read from Excel sheets(.xlsx). Being new to C#, I want to know if using NPOI is a good option to read/write data from Excel or using Interop in C# is a preferred. I personally prefer NPOI as I feel it is easier to use. This could be because of my exposure to Apache POI when I used Java and Selenium for automation. Kindly help.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
https://support.microsoft.com/en-us/kb/257757
Don't use Office Interop in web environments.

At first, as mentioned already, Interop requires actual Excel application to be installed on server, which is not always a good idea ar may even be not possible at all (i.e. if you are yousing Azure Web Apps). I'm currently working on a project which we have rewritten using Interop, but now are going to migrate to NPOI mainly because of it's speed: some tasks require around 5-8 seconds using Excel Interop, because it actually launches full Excel app and communicates with it via RPC. NPOI works directly with Excel files and today while testing one heave action was performed in just around 300 milliseconds including saving modified workbook to new file.
So if you have to work specifically with old binary .xls files NPOI is good choise. If you are going to work with modern OpenXML files (.xlsx), take a look at https://github.com/closedxml/closedxml

The microsoft solution to office document automation is Open Xml : https://msdn.microsoft.com/en-us/library/bb448854(v=office.15).aspx

Opening, calculating, closing MS Excel spreadsheet without Excel installed [EPPlus]

I'm using EPPlus library to create spreadsheets (reports). In my app every new document first opens an older report to get previous results. The problem is when getting data from cells containing formulas - unfortunately EPPlus doesn't have a calculating engine. To make it work I need to open the old report in Excel, save changes (formulas are calculated), and then new report is created properly. If i don't do it, then the values from formula-cells are blank.
Is there a way to simulate (not doing it manually, but with code)
opening, calculating, closing an excel spreadsheet without excel
installed?
Any ideas how to workaround it?

EPPlus can calculate formulas from version 4. See this page - https://epplus.codeplex.com/wikipage?title=About%20Formula%20calculation&referringTitle=Documentation

http://www.microsoft.com/en-us/download/details.aspx?id=5124
OpenXML is what I used when I didn't have access to Office.... you can build office documents using it without having Office on your machine.... For me there was a learning curve and a lot of googling to figure things out.
I still don't know all of the ins and outs of it, but it worked for what I needed to do.

"Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment." ...but at the same time they give a lot of useful links on OpenXML manipulation - worth visiting.
http://www.spreadsheetgear.com/ - but it's very expensive, $999/subscription
NPOI (a C# port of Apache POI - the Java API for Microsoft Documents). The Java version can read calculated values, so maybe C# version also could.
Office Integration Pack - don't know if it can calculate

So I really can't use Excel Object Model to be used server-side?

I'm trying to develop a c#/asp.net application to extract data from a SQL server and have it formatted in an excel spreadsheet. I have been practicing with excel object model and recently stumbled upon this: http://support.microsoft.com/kb/257757 Considerations for server-side Automation of Office
From what I understand I really can't use Excel Object models? And if not what are other solutions/advice besides whats suggested in this article and 3rd party apps I can use?

From that article:
Microsoft does not currently recommend, and does not support,
Automation of Microsoft Office applications from any unattended,
non-interactive client application or component (including ASP,
ASP.NET, DCOM, and NT Services), because Office may exhibit unstable
behavior and/or deadlock when Office is run in this environment.
What this means is that Microsoft won't explicitly prevent you from trying (the licensing allows you to try.) However, if there is a problem, it's up to you to figure out how to fix it.
There is a better option:
Create Excel (.XLS and .XLSX) file from C#
This will allow you to create the file for download without having to use Excel automation on the server side.

I can recommend the SpreadsheetGear library, it has all the Excel functions in one managed dll:
http://www.spreadsheetgear.com/

You 'can' use Excel automation on the server side. However you will be breaching licences ,may run into security problems and generally experience other odd behaviour, especially if you have more than one user using it at a time. I would suggest that you dont do it.
If the data you want to write is simple enough just do it as a csv
If not and you really have to write a spreadsheet look for a 3rd
party component that writes excel files. I only know of one off
the
top of my head and thats Aspose.Cells, but that is quite
expensive.

Reading a Excel 2007 Spreadsheet in C#

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.

Programmatically access a Microsoft Project (MPP) file from C#

What are my options for programmatically accessing a Microsoft Project file? What are the pros and cons of each approach?
I will basically need to import all data from the file into another data structure. Using the Office Interop assembies is low on the preference scale.

The MPXJ (mpxj.sf.net) library comes in both Java and .Net flavours and will allow you to read and write multiple Microsoft Project file formats using a single consistent API. I am aware of commercial products which use both the Java and the .Net versions of MPXJ without any issues.
Disclaimer: I'm the maintainer of MPXJ.

You may use Aspose.Tasks for .NET. This component allows you to work with Microsoft Project files. It doesn't require MS Office to be installed on the server, unlike Office Interop. The API is very simple and easy to use. And it provides a rich set of features to read, edit, write, and convert MPP files.
This component is a normal .NET assembly which can be used with your .NET applications. It works on any Windows OS and in 32/64-bit environments as well.
Disclosure: I work as developer evangelist at Aspose.

Here are the options:
Interop (messy and horribly slow for
large projects)
Save project in XML and work with it
(messy)
Save project in the database (that's
not publishing and it is available
for project 2003 only - see ODBC
option while saving). I've seen it
being used a lot in the integration
scenarios
Projette (commercial, $10 per
license)
ILog Project Viewer (also
commercial)

The Microsoft Office API provides programmatic access to MS Project. I have only used it for Word and Excel so I don't know how rich the interface is - you will have to do some digging around on MSDN to find out what you can and can't do.
One of the Java projects at my company uses a commerical product by Aspose which allows applications to manipulate Office documents including Project. It works well for their purposes, but again, they have only used it for Word and Excel so can't offer much advice on Project.
EDIT (2019): I can confirm that it is a very capable product.

Sourcefourge.net offers a component in Java which can be integrated with .net applications to read MPP files upto MPP 2007 the link is
http://mpxj.sourceforge.net/getting-started.html