I am working on a C# .NET v4.0 application which includes generation of Word documents. The application uses the version 14.0.0.0 of the Microsoft Office Interop Word library.
My computer is running Office 2010 (Office14) and I am wondering what are the differences between the versions 14.0.0.0 and the 15.0.0.0 for the library?
Is there any obligation to use one or the other of these two libraries depending on which version of Office I am running?
If you link your app to the version 14.0.0.0 (Word 2010), it will work with Word 2013 (version 15) if you use the "Embed Interop Types" feature in Visual Studio.
If you link to 15.0.0.0, it will not work with Word 2010.
Linking to 15.0.0.0 will let you access to new functionality of 2013 if any.
If you don't need any automation of the application (Word) itself then I would recommand to use the offical Open XML SDK 2.5 for Microsoft Office to process any xlsx docx or pptx.
Download Open XML SDK
Update
I think it does not matter which version. More important is that your implementation works with the version that the customer has currently installed! Maybe or maybe not there could be some breaking changes between the interop interfaces between major versions.
Related
The "Interop"-Interface for Office seems to have some problems interacting with "Microsoft Office" when the "Microsoft Office"-version is newer than 2010. When using the "AddComment"-Function in "Microsoft.Office.Interop.PowerPont.Shapes" I get an "System.NotImplementedException".
In "Microsoft Office 2010" or older everything works fine.
additional information:
I for myself have only a 2010-version of "Microsoft Office". The issue was reported by co-workers which have newer versions.
The current version number of my "Interop.PowerPoint.dll" is "2.6.0.0".
questions:
Is my "Interop.PowerPoint.dll" too old?
What is the version number of the newest existing "Interop.PowerPoint.dll"?
Is there any way to get the newest "Interop.PowerPoint.dll" even if I still have only a 2010-version of "Microsoft Office"?
Can my "NotImplementedException" have some other causes?
Is there any way to work around this Problem? I just want to make my program write comments into a "PowerPoint" file.
The interop assembly doesn't contain any sophisticated logic or implementation of the method. The goal of the interop assembly is to marshal your calls from a managed code to the unmanaged COM world. So, if the method fails the problem should be searched in the COM server implementation.
You can download PIAs Microsoft Office 2010: Primary Interop Assemblies Redistributable or generate in Visual Studio on your own.
You may also find Office PIAs in the Visual Studio installation folder if Office extensibility feature was selected while installing it. Read more about that in the Office primary interop assemblies article.
Starting with Visual Studio 2017, these copies of the PIAs are installed to following shared locations on the development computer:
%ProgramFiles%\Microsoft Visual Studio\Shared\Visual Studio Tools for Office\PIA\
%ProgramFiles(x86)%\Microsoft Visual Studio\Shared\Visual Studio Tools for Office\PIA\ - on 64-bit operating systems)
I have used Shared Add In(C#) to develop an Excel Add-In. In the initialization, I had no problem with loading excel-dna file .xll on Office 2010. However, there is problem with running on either Office 2013 or 2016, showing that "function is Invalid".
AddIn udfAddIn = applicationObject.AddIns.Add(progID, true);//the exception is "AddIns is Invalid"
udfAddIn.Installed = load;
Please help me. I would like to know how it (.xll file) works on Office 2013 and 2016 by shared add in. Thanks!
You are mixing two different technologies when you make a Shared add-in (a COM add-in) with Excel-DNA. I'm surprised it worked with Excel 2010.
The best approach is to make a new Class Library project (targeting .Net Framework) and then install the ExcelDna.AddIn package from NuGet. Then follow the instructions in the readme file that pops up. You should have a starter add-in that works in both Excel versions.
The best place for Excel-DNA support is the Google group at https://groups.google.com/forum/m/#!forum/exceldna
I have already developed Oulook Add on using Visual Studio 2010 with VSTO
It works for OFFice 2007, 2010 and 2013
Now Office 2016 has been released. is the same application will work for 2016?
Is there any changes in VSTO and PIA Version for Office 2016? is those has been released?
if not when will be released? is there any web page to track the release?
If any, Whether i need to install those?
Appreciated for getting a development guidance in Office 2016
It doesn't matter what PIA version you use in the project. The add-in should work correctly until you use members introduced in newer Office versions. Read more about that in the Running Solutions in Different Versions of Microsoft Office article.
Note, you can use the late-binding technology for accessing properties, methods and events in newer Office versions even when using older PIAs. See Type.InvokeMember .
There is no separate installer for Office 2016 PIAs. You can install them as a part of Office 2016. See How to: Install Office Primary Interop Assemblies for more information.
What is best way and practics parsing excel files without using COM interop or OLEDB connection
You could use NetOffice, im currently using it in my project. Its pretty cool,
Code Sample for Excel
Features
Office integration without version limitations
All features of the Office versions 2000, 2002, 2003, 2007, 2010, 2013 are included
Active support in version independent development (please scroll down)
Syntactically and semantically identical to the Microsoft Interop Assemblies
No training if you already know the Office object model, use your existing PIA code
Reduced and more readable code with automatic management of COM proxies
Usable with .NET version 2.0 or higher
Easy Addin Development
No deployment hurdles, no registration
No dependencies, no interop assemblies, no need for VSTO
Visual Studio Project Templates and Wizards available Photo Gallery
I have had good success with ClosedXML.
Let's say I am using SharpDevelop/VS to develop an app that uses PowerPoint.
Do I need to recompile the app so there is a build for each version of MS Office?
I have MS Office 2007, but I would also like the app to work with Office 2003 and later, without having to recompile the app for each version.
Do I just need to install the appropriate Office Interop redistributable package/msi on the client machine, and ship my app as is?
Thanks in advance for your help.
If you're using the Microsoft.Office.Interop libraries you just need the 2007 version, it will be backwards compatible with older docs
I have found that you should build against the oldest MS Office you have. We still use MS Office 2000.
The the thought behind this:
Everything MS Office 2000 can do any later version of MS Office can do.
A lot of things MS Office 2007 can do is impossible to do in earlier versions
of MS Office.
I absolutely agree with Nifle. Use the OLDEST ones you can find. If you use 2007, there is a very good chance it will not work with older versions.
Since I did not want to install the oldest Office version on my development PC, I used Virtual PC to create a "final build" environment. I develop with my regular PC then move the source files over to the Virtual PC with Office 2003 and VS installed, and create the final customer build there.
You will need to edit the CSPROJ file to reference the older Office libraries with this method. You can do that by just opening VS on the build virtual PC, removing the references to Office and adding them again.
Just to confirm this with anybody that is trying this. I have a .NET 4 project that references the 15.0 PowerPoint Interop library and the Office 15.0 library (Office 2013). I setup the project to "Embed the Interop Types".
I setup a virtual machine with Office 2007 Ultimate on and ran the application (without copying any additional DLLs). It correctly interacted with PowerPoint to extract the data my application was looking for.
The Interop libraries are backwards compatible from my experience.