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.
Related
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.
Recently Microsoft introduced the Office Add-ins architecture which allows for developing add-ins hosted remotely and run within IFrames inside office. I have read a lot trying to understand whether this architecture is meant as a replacement for VSTO or do they have separate use-cases. VS 2015 has templates for both.
In my specific case, I want to develop an add-in that extends Excel 2016 with custom import functionality (e.g. custom CSVs, TSV, or even XLSX). I can't tell which type of project I should go with.
Given the amount of legacy applications developed as COM and VSTO add-ins I find it hard to believe Microsoft would drop support within the next 10 years.
For me the most important differentiators of one approach vs. the other are:
COM/VSTO Office add-ins
Access to complete object model
Local machine interaction, e.g. file system
Available on Windows since Office 2007
JavaScript Office Add-ins
Portable between Windows, OS X, iOS etc. (not complete everywhere yet though)
Easy integration with online services
Easy distribution, no need to worry about installers
In your case I'd ask myself these questions:
Will there be a need to support other platforms besides Windows in the future? > JavaScript API
Are the requirements covered by the current JavaScript API implementation?
I've found that VSTO isn't 100% implemented either. I've given up developing VSTO for Project, got hit by too many issues. Instead I've developed everything in VBA and have perfected some neat ways to install, distribute and update VBA macros.
I'm programming simple powerpoint add-in, that sends xmlhttp request on slide change. Is it possible to create one add-in compatible with more vesions of powerpoint? Or do I have to develop it for each version separately? How to develop add-ins for more versions of MS Office without installing all of them?
You don't mention what tools you're using to develop the add-in. My understanding is that if you want to write for multiple versions of PPT using Visual Studio, you're more or less out of luck, unless you have multiple computers or multiple VMs and whatnot.
If you're using VBA, then it's not especially difficult to write one add-in that's compatible with all versions as far back as 2000. There are a few tricks to it, and it becomes a lot simpler if you leave PowerPoint 97 out of the mix.
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 plan on developing Excel Add-ins and I have looked around on ways of getting it accomplished. What I have found from expert views on various forums whom suggest using third party XLL development environments (XLW, ExcelDNA and host of others) instead of Excel SDK development 2007 with C++ as the latter option requires steep learning curve and for novices such as me would require managing low level details such as memory management
So my question is whether the XLL produced or developed using the 3rd party tools (XLW, ExcelDNA) would run on users Windows system that do not have .net runtime support. There are only 1 or 2 sample tutorials on the web about development of XLL with Excel 2007 SDK using Visual Studio.net and users comments on those tutorials suggest that an XLL developed in Visual Studio.net using Excel 2007 SDK are not runnable on Windows that do not have .net runtime
If you develop your add-in with C# or VB.NET (either with Excel-DNA or XLW), it will require the .NET runtime to be present on the client machines. If you develop the add-in with C++ (with XLW or another C+-based toolkit like XLL+) your add-in will not require the .NET runtime.
By default XLW uses the dynamically linked C runtime so you need to be sure the target machine has the appropriate version. http://xll.codeplex.com uses static linking so you can be sure your xll will run on any Windows machine.