I have a need to replicate a framework I built ij Java using the Apache POI api to read data from MS Excel. I have no idea what to use that is an equivalent of apache POI library. Any ideas please anyone?
It depends on what you want to do.
One option is NPOI, which is a .Net port of Apache POI to .Net
Another option is to use IKVM, and then Apache POI itself directly from within .Net.
You could use Open XML SDK for manipulating MS Office document formats since Office 2007.
Related
I manage a Windows Server 2016 that has Lucee 5.3.10.97 with IIS, and bundled within Lucee is Apache POI 2.5.1. I have requirements to update this to at least Apache POI 3.17. Can I just drop a newer JAR of poi 3.17 over the 2.5.1 bundled in Lucee, or am I unable to do so because this jar is referenced somewhere?
As far as I understand it, Lucee doesn't include POI in its core any longer. The older version you are seeing is probably the one bundled with the Tika library.
The simplest way of using a more recent version of POI is to install the POI Lucee Extension which has POI 5.0.0. Look for it in the Extension > Applications section of the Lucee server admin UI (click the "Pre Releases" button if you don't see it). Or you can download the .lex file from https://download.lucee.org/ (scroll down for extensions) and drop it in your lucee-server/deploy folder.
As Lucee uses OSGi, the different versions won't interfere with each other.
I'm using the Excel Interop API for manipulating excel sheets, because this seems to be the best api for using formulas.
My question is that how wide is the support for this API?
For example if someone who has an older or newer version of Microsoft Office than me, will they be able to use the software?
I'm using it with Office 365.
My question is that how wide is the support for this API?
For example if someone who has an older or newer version of Microsoft Office than me, will they be able to use the software?
The answer is yes, your software can be run with different Office versions. You just need to make sure methods and properties exist in the installed version by checking the host version and making a decision to call a particular method or property introduced in recent versions.
So, I'd suggest using the lowest version of interops libraries which corresponds to lowest Office version supported by your software. By using lowest interop version you can be sure that you deal with properties and methods available in all Office versions and no exceptions will be thrown at runtime.
If you need to use methods and properties available in latest Office versions you may consider using the late-binding technology available in .Net applications with System.Type.InvokeMember method. Read more about that in the Supporting several Office versions in an add-in. Interop assemblies and late binding. article.
is it possible to generate a worksheet like excel on a machine where Excel is not installed.
Currently I am using Aspose.Cells ImportDataTable function but it requires Ms Excel as a pre-req. Is there any way that it can be done on a machine where MsOffice is not installed
I am afraid, your understanding is not correct. Aspose.Cells APIs are built using managed code that do never need Microsoft Office or Microsoft Excel to be installed on the machine to work with its features or manipulate Excel document formats. It should be Microsoft Office automation alternative and an independent library.
Note: I am working as Support developer/ Evangelist at Aspose.
I have a requirement where in I need to scan Office documents and remove any metadata found embedded in the file/document. I am new to developing applications on Microsoft Office and found that I could either use the Platform Interop Assemblies or the OPENXML SDK to work with Office docs (word, excel and powerpoint).
However, I couldnt find any source/link which explains the difference between PIA and OPENXML. Could anyone please explain as to when which option needs to be looked at and which one is easy to work with (ie., less effort on learning curve)?
The huge problem with PIA is you will be dealing with COM interops unmanaged environment.
Here are the differences
I have an multiple assembly C# Excel addin which passes embedded interop types across assembly boundaries. When I run this in an Excel process configured to use .NET 3.5, everything is OK. When I run this in an Excel process configured to use .NET 4.0, only controls with application logic defined in the addin assembly itself load. I think I understand why, since the handling of embedded interop types changed significantly in .NET 4.0, so that they must not cross assembly boundaries. What confuses me is that I thought in .NET 4.0 multiple instances of the CLR could be hosted in a single Windows process. If my addin targets .NET 3.5, why can't it just run in a .NET 3.5 CLR instance owned by Excel? Why is Excel trying to run my addin in .NET 4.0? It's not really an option to rewrite the addin, but it needs to install for a client who also use .NET 4.0 addins, so it's not OK to play with registry keys or the Excel.exe.config files... Any help will be REALLY appreciated!
The answer to the question in your title is 'yes'. The .NET runtime version 2.0 (which is the runtime version used by the .NET Framework 2.0, 3.0 and 3.5) can run side-by side in a process with the .NET runtime version 4.0 (which is the version number that will also be used by the upgraded .NET Framework 4.5).
However, the VSTO case is not so simple, since there is interaction between Excel and the VSTO runtime to decide what to load. VSTO 4 basically includes separate versions of the Office extensions targeting .NET 3.5 (under the .NET 2.0 runtime) and .NET 4.0. Depending on which version of the VSTO 4 office extensions you target, you uses classes (compatible with older VSTO) or mainly interfaces, so the VSTO API design and your code is a bit different too, depending on which version of the VSTO 4 office extensions you use. Then deployment and loading of your VSTO add-in depends on which version of the VSTO Office extensions you target.
So the version of the .NET runtime that your VSTO 4 add-in loads in is linked to how you made the add-in. Read more here: http://msdn.microsoft.com/en-us/library/bb608603(v=vs.100).aspx and http://msdn.microsoft.com/en-us/library/ee712596.aspx.
If you have other COM components, it could be that the COM components are activated in a different version of the runtime (say in the 2.0 runtime) and are then not accessible from the 4.0-runtime based add-in. The way COM interop type changed in .NET 4.0 would typically make things work better, since the runtime now correctly identifies types defined from different assemblies as 'the same' based on GUIDs etc.
To make life easier, I can also suggest Excel-DNA (which I develop). It is a free and easy add-in library for making full-featured Excel add-ins in .NET, without using VSTO. Excel-DNA allows you to target any version of Excel, and any 2.0+ version of .NET.
I'm not familiar with developing excel addins but yes you can do that.
However using a different versions of clr in the same process is to done automatically.
You can read the details here.