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.
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 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.
I have an outlook plugin built with Visual Studio 2010 (.net 4.0 Client Profile), that works fine in Outlook 2007 and Outlook 2010. I just tested on 2013 and even installing the addin seems to crash. After googling, I see a few examples of issues people have faced but fundamentally can't get a straight answer to this question:
Is there any prerequisite that would not allow a VS 2010 Outlook addin to just work on 2013 or do I need to upgrade Visual Studio and Create an Outlook 2013 specific version of my addin?
The Running Solutions in Different Versions of Microsoft Office article describes all details. It states the following:
If you developed solutions for Office 2010, you can run the same solutions in Microsoft Office 2013. Solutions that were created by using Visual Studio 2013, Visual Studio 2012 or Visual Studio 2010 can run in Office 2013, Office 2010, or the 2007 Microsoft Office system.
What is the target .Net framework of your add-in? Did you try to debug the code? Do you get any exceptions?
Do you have Outlook 2013 on the machine you have the add-in project on? If you do, you can debug from VS 2010 by setting the "Start external program" in the Debug tab of the project properties window to the Outlook 2013 .exe. When I created my add-in I was able to debug it using whatever version of Outlook was on my development computer and I don't remember changing anything other than the external program path.
If you are using setup project for the installation it needs a different ComponenedId when you create its launch conditions. You'll need two different setup projects to install on Outlook 2010 and 2013. Here are the Office 2013 PIA keys and Office 2010 keys.
Did you try enabling the add-in again? It won't run after its in the disabled queue. After you re-enable it from the disabled add-in screen, you can then check the box in the COM-AddIn screen to have it load which then should prompt you more detail since you set the VSTO_SUPPRESSDISPLAYALERTS variable about what may have happened in the first place.
The problem can be that the add-in had been hard disabled by Outlook. Notice that the add-in did not show up under Inactive Application Add-Ins, but rather under Disabled Application Add-Ins. That makes a difference: In the latter case, just going to the COM-AddIn screen and ticking the check box is not enough to solve the problem.
Follow these steps for hard disabled add-in?
Goto the Manage box, change COM Add-ins to Disabled Add-ins, and then
click Go. Select the add-in and click Enable. Click Close. OK, now
the add-in can be loaded again:
In the Manage box, change Disabled Add-ins to COM Add-ins, and then
click Go. select the check box next to the disabled add-in. Click
OK.
Reference THIS site for further details.
I vaguely remember encountering an AddIn crashing on installation in the past... resolution is:
Install Visual Studio 2010 Tools for Office Runtime on the target machine.
Try the VSTO AddIn install again and you wont get the crash during installation.
Before trying to install it, you can try to run it trought the debugger to have more info on the real problem. As far as I remember, you just need to go to your project properties and change the launched version of outlook while debugging...
You can follow this link for more info : http://www.greycastle.se/vsto-project-office-target-version/
Assembly Loading issues are difficult to debug because there are at least two layers to this when dealing with Managed and Native code.
When an executable is started the native loader must find the file, load it into memory along with all the dependent DLLs to make it run.
The native loader looks into the assembly manifest to determine this information and then simply hunts down all the DLLs and load them into memory (in order).
You can easily see this process using WINDBG and pointing to an EXE and running it from Windbg. The list of modules being loaded is the native loader at work.
If a dependency is a .NET managed code assembly then the native loader transfers the loading request directly to the managed loader, known as "Fusion".
You can easily set up the FusionLOG viewer to see what is happening http://msdn.microsoft.com/en-us/library/vstudio/e74a18c4%28v=vs.100%29.aspx
Failures of loading at either the managed layer or within the managed layer are easily spotted either through WINDBG for Native or the Fusion Log View for Managed code.
A few hints on Managed DLL loading: If an assembly holds a reference to a dll that is not included in that assembly, there is a strict order of "probing" which is followed to find the dll. There will be a minimum of three attempts to find the DLLs in different places such as in the assembly, in the program root path and in the GAC. If the three attempts fail, loading is stopped at that point and the program will not run. When this happens it is often considered a system level environmental issue; however, in reality it's a programming issue because unless pre-requisites are fully know by the system administrator there is no way they can guess at this stuff. If you are a programmer who is including other dependent dlls you should always consider whether or not to place them into the assembly to stop this problem. Otherwise you, the system admins, and folks using your program will have to wait until the root cause is determined which takes a long time.
You may say, well I was told by another department to use this dll and I have no idea what the other dependencies are! This is no excuse, as there are excellent tools such as ILDASM and even managed code Dependency walkers that will tell you everything that's needed. The best way to package these "other" dlls is to simply include them in your assembly.
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 want to create an add-in (a ribbon precisely) for MS Excel by using Visual Studio C# 2010 Express. I have searched and read about it here and here and somewhere else. However, when I want to create a new project I don't see any template as described, I don't see even the Office tab. Is it because I am using the Express edition? I think it shouldn't be. Because in this official comparison they say all editions are capable of office development.
What can I do to develop this add-in?
According to this post on the MSDN forum, Visual Studio Tools for Office are not available in the Express edition. I'm not sure where you're reading that on the comparison page (a quick glance said nothing about the Express edition).
A good alternative to VSTO for making an Excel add-in with .NET is Excel-DNA (which I develop). It is a free library that integrates your .NET assembly with Excel using the C API (as an .xll add-in). You can create user-defined worksheet functions (UDFs) for Excel (which are not supported by VSTO), and make ribbons, RTD servers. And you get easy deployment (a single .xll file) without needing any registration or admin rights, even for ribbons and RTD servers.
Another option, if you just want to integrate through the COM interface and not make UDFs or use the specialized Excel features, is NetOffice. The project give you a version-independent set of interop assemblies for Office and Visio, and allows you to easily make add-ins targeting different versions of Office. NetOffice can also be used as your COM interop library in an Excel-DNA add-in.
Both of these directions will work fine under the Express editions of Visual Studio, as well as in the free SharpDevelop IDE.