Interop Files

Add-in Express™ Support Service
That's what is more important than anything else

Interop Files
Is there a need for us to package interop files in the installer? 
AppDev




Posts: 26
 Joined: 2016-06-22
Hello Andrei and team,

I just wanted your opinion regarding files included in the package/installers.

So our old installers have the "microsoft.interop.outlook.dll", "microsoft.vbe.interop.dll", "office.dll" and the "stdole.dll" included in the installer for our outlook addin.

Since I am not so sure whether this is a good practice or not, I would like to ask your advice if this is wiase or not? I was thinking these files should be excluded and the addin should link with the one in the host machine.

Any insight about this?

Thank you!
Posted 02 Jul, 2020 04:44:32 Top
Andrei Smolin


Add-in Express team


Posts: 18821
 Joined: 2006-05-11
Hello AppDev,

AppDev writes:
I was thinking these files should be excluded and the addin should link with the one in the host machine.


If the interop version found on the PC is different from the one used while building the add-in, you'll get this exception:

Exception Message: Could not load file or assembly 'Microsoft.Office.Interop.{Office application here}, Version={application version}.0.0.0, Culture=neutral, PublicKeyToken={something}' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

If you use .NET 4.X, we recommend to embed the interops: select such a reference and set Embed Interop Types = true in the Properties window. Then rebuild the add-in project and update the setup project(s): you may not deploy that interop any longer.

Here's a citation from https://docs.microsoft.com/en-us/visualstudio/vsto/designing-and-creating-office-solutions:

By default, Office primary interop assemblies (PIAs) do not need to be installed on end-user computers if the Embed Interop Types property of each Office PIA reference in the project is set to True, which is the default value. In this scenario, the type information for the PIA types that are used by your solution is embedded into the solution assembly when you build the project. At run time, the embedded type information is used instead of the PIAs to call into the Office application's COM-based object model. For more information about how types from PIAs are embedded into your solution, see https://docs.microsoft.com/en-us/dotnet/framework/interop/type-equivalence-and-embedded-interop-types.


Also, this approach solves an issue when your add-in starts while Office updates; the issue produces this exception:

Exception Message: Could not load file or assembly 'Microsoft.Office.Interop.{Office application here}, Version={application version}.0.0.0, Culture=neutral, PublicKeyToken={something}' or one of its dependencies. Access is denied.

The VBE interop isn't required typically. You need it only if your add-in uses the VBA Extensibility object model e.g. to create VBA macros.


Andrei Smolin
Add-in Express Team Leader
Posted 02 Jul, 2020 05:21:23 Top
AppDev




Posts: 26
 Joined: 2016-06-22
Hi Andrei,

Thank you for a really really awesome response.

You are correct, we are having this issue right now in some of our end users :

Exception Message: Could not load file or assembly 'Microsoft.Office.Interop.{Office application here}, Version={application version}.0.0.0, Culture=neutral, PublicKeyToken={something}' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)

Two final clarifications though :

1. With "Embed Interop Types" set to "true", Does the following statement mean, I don't have to package the interop files in my installer, so no interop files are deployed in the target machine?

Then rebuild the add-in project and update the setup project(s): you may not deploy that interop any longer.


2. Interop files have dependencies. Like "microsoft.interop.outlook.dll" requires stdole.dll and office.dll. If I set the "Embed Interop Types" to true, then these dependencies will be embedded as well. Right?


Super Thanks!
Posted 02 Jul, 2020 08:43:31 Top
Andrei Smolin


Add-in Express team


Posts: 18821
 Joined: 2006-05-11
Great!

You don't need to deploy an interop assembly having Embed Interop Types = true as the information the interop provides is included in your add-in assembly. All other assemblies, including interop assemblies having Embed Interop Types = false (BTW, this is the default), should be delivered to the target machine.

office.dll is an interop assembly; it can be embedded or not. If it is embedded, do not deploy it.

I don't know about stdole. It is added to an add-in setup project when I create it. I assume you should deploy it.

@All,

If I find anything about stdole.dll, I'll post that info here. If you know something and the thread is closed (it closes automatically after 30 days of inactivity), ping me using any contact form on the web site and I'll reopen it.


Andrei Smolin
Add-in Express Team Leader
Posted 02 Jul, 2020 09:14:11 Top
AppDev




Posts: 26
 Joined: 2016-06-22
Hello Andrei,

Thank you very much for your quick responses and support.

For now, I have set EmbeddedInteropTypes=True for Microsoft.Interop.Outlook.dll and removed it from the list of files included in my package. Wit the interop's removal, office.dll was also removed from the installer files.

I will give this a spin now.

Thank you!
Posted 02 Jul, 2020 21:17:11 Top