I had to import an older project (in .Net 2) into Visual Studio 2013, it makes use of the Microsoft Primary Interop Assemblies.
Visual Studio said that I need to add references to the project. Now I went and did some reading and apparently Microsoft has only released the PIA for office 2010? (I have Office 2013)
Now what I would like to know is.
Can I get it to work with office 2013 and be backward compatible?
And if so is this a good route to go for the future? Is it going to be compatible? Because I see you need .Net 2 (at the latest) and Windows 8 comes with 4.5 and not 3 (by default) and most new computers are going to have Office 2012 or 2013.
PIAs are a historical artifact, required only by old .NET versions (before v4). They have been thoroughly and elegantly replaced by the "Embed Interop Types" feature, also known as the "No PIA" feature. Supported since Visual Studio 2010, you'll find it back in the Properties window when you select a reference assembly. It defaults to True. A good video that covers the underlying technology is available here.
Which is the reason that Microsoft doesn't publish the PIAs for Office 2013, they expect you to embed the interop types instead.
The feature is very desirable, it avoids your customer having to install the PIAs on his machine and for you to include them with your installer. Solving the issue when neither takes care of it, an entirely too common mishap. In addition, the PIAs for Office are very large, the great advantage of embedding the interop types is that your assembly only contain the types that you actually use. Many megabytes reduced to a few kilobytes.
The workflow is a little different. Instead of adding a reference to the Microsoft.Office.Interop assemblies as available in the Add Reference dialog, .NET Framework tab, you now use the COM tab. And pick, say, "Microsoft Excel 15.0 Object Library" to generate the interop types for a program that uses Excel. If you load an old project that previously used PIAs then just remove those reference assemblies and add them back from the COM tab.
Do note that a feature is lost, intentionally targeting an old version of Office that you don't actually have installed on your dev machine is more difficult. If that's a requirement then you still need the PIAs for that version, force the Embed Interop Types to True in the Properties window. Actually doing this is questionable, Microsoft has a hard time keeping new Office versions completely compatible with old versions. They've kept it up for 15 years now but it has been running out of steam. A worst-case scenario is targeting a newer version than you have installed on your machine, that's liable to make your program crash with very hard to diagnose exceptions like AccessViolationException.
Do note that you have to make small modifications to your code to allow it to work. The synthetic "XxxxClass" classes are not embedded, just the "Xxxx" interfaces. Simply remove the word "Class" from the new statement.
VS 2015 Community with Office 365 - for whatever reason the Add from the COM object does not work. The solution is go into the GAC and find the interop assemblies, copy them to a temp directory, then add to your project like any DLL.
Also, if you don't know by now, Windows 8 does have older versions of .NET Framework but they aren't installed by default. Go to Program Features ---> Add features to Windows ----> and the first check box should be .NET 3.0 and maybe 2.0. Note, if you are on a WSUS server you will need to tell Windows to grab the files from the Windows Update servers. Hope it helps!
Officially there is no backward compatibility of the PIA for Office. In fact it works.
For backward compatibility reasons I'm using the PIA for Office XP since several years and it works fine with Office XP, 2003, 2007 and 2010 (not yet tested with 2013) and on Windows XP, Vista, 7 and 8.
For compatibility with the different versions of Windows I'm using the .NET framework 3.5.
For the future... it depends of what you are doing with the PIA. If possible it is far better to directly deal with the Open XML files or to create an add-in for word/excel.
I just found out that the Visual Studio 2013 express does not have office-support anymore. So you need at least the pro-version to make it work.
Related
My settings :
- Office 2010 is fully installed and running with default settings including .Net development,
- Office 2010 Primary Interop Assemblies (v14) are installed (checked with control panel programs list)
Problem : In C# or F# projects, I cannot add a reference to Microsoft.Office.Interop in the Solution Explorer window of Visual Studio 2013 Community Edition. Interop are not listed anywhere (COM, Assemblies,...)
Question : Does VS 2013 Community Edition forbid reference to Office PIA as opposed to full VS 2013 PRO ?
If not, what should I check ?
Thanks.
There is no generic reference for Office, rather, they are application specific. Under the COM tab, you can add a refernce to any of the following. The version number will vary based on the version of Office you have installed.
Microsoft Excel 14.0 Object Library
Microsoft Outlook 14.0 Object Library
Microsoft Powerpoint 14.0 Object Library
Microsoft Word 14.0 Object Library
The only real difference between the Community and Pro SKUs is that Community omits the Office dev scenarios.
My guess is that the list of dirs that are used to populate the "add reference" dialog is modified in Community, with well-known Office binary dirs removed. This is just speculation, but it would explain what you are seeing.
If you can find the location on disk of the PIAs, you should still be able to add a reference via plain "browse." AFAIK, Community doesn't explicitly block this, it just doesn't help like Pro+.
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.
I have been trying to create a deployment for a C# Outlook 2003 add-in. It requires only NET 2.0 and relies on IDTExtensibility2 (of Extensibility.dll). Upon making sure Office 2003 PIA are installed the add-in still won't register because of Could not load file or assembly 'Extensibility, Version=7.0.3300.0, Culture=nuetral, PublicKeyToken=b03f57f11d50a3a' or one
of its dependencies. Strong name validation failed. (Exception from HRESULT:
0x8013141A)
I don't think deploying Extensiblity.dll is legal and I could not make it work even if it was. So how to make sure it is available on the target PC?
I could not find an adequate solution anywhere.
The solution is developed in VS 2010.
If your outlook add-in is signed using a strong name key then any external libs that you reference will also need to be strong name signed.
I've had a similar problem to yours in the past where 3rd party libraries were not signed with a strong name.
After doing a bit of searching around I came across this Microsoft Support article that provides a resolution.
In brief:
When you use Microsoft Visual Studio 2005 to create add-ins, smart
documents, or smart tags, you may experience the following symptoms:
The add-ins, the smart documents, or the smart tags cannot be loaded in any Microsoft Office application.
The add-ins, the smart documents, or the smart tags do not run in any version of Microsoft Office.
and their resolution:
To resolve this problem for Visual Studio 2005 developers, a
redistributable version of the update for Visual Studio 2005 is
available.
Found Extensibility.dll in
\Visual Studio Tools for Office\PIA\Common
folder. Copied it to the project folder.
I have VSTO 2010. Added the reference to my project, and the compile error went away. Same version on the error: 7.0.3300.0. VSTO is distributed freely by Microsoft for developers, to create solutions for Microsoft Office, but the license document enclosed with VSTO 2010 doesn't allow you to make copies of it except for your own use. That being said, I would pester Microsoft about the dll, as obviously you need it for your project. Obviously, they should have added a clause to the license to allow distribution of the dll by developers.
My dev machine has 2007 installed and the project references the corresponding version of PIAs but I would like my application to be able to run with 2003 at least when deployed. I tried setting the Specific Version property of the reference to false but this didn't work. My Visual Studio version is 2005, BTW.
Use late rather than early binding (in other words, don't reference any PIAs). This MS kb article shows the difference.
However, to simplify development it can sometimes be easier to start off with early binding against the earliest version you want to support (so you get Intellisense support etc in Visual Studio) and then when you're finished, you remove the references and change it over to late binding.
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.