What's the Difference Setting Embed Interop Types True and False in Visual Studio

What's the difference setting Embed Interop Types true and false in Visual Studio?

This option was introduced in order to remove the need to deploy very large PIAs (Primary Interop Assemblies) for interop.

It simply embeds the managed bridging code used that allows you to talk to unmanaged assemblies, but instead of embedding it all it only creates the stuff you actually use in code.

Read more in Scott Hanselman's blog post about it and other VS improvements here: CLR and DLR and BCL, oh my! - Whirlwind Tour around .NET 4 (and Visual Studio 2010) Beta 1.

As for whether it is advised or not, I'm not sure as I don't need to use this feature. A quick web search yields a few leads:

• Check your Embed Interop Types flag when doing Visual Studio extensibility work
• The Pain of deploying Primary Interop Assemblies

The only risk of turning them all to false is more deployment concerns with PIA files and a larger deployment if some of those files are large.

Embed Interop types issue

As already mentioned, the problem is that there is that Powerpoint is not installed on the client machine.

The powerpoint object is implemented in a COM type library and installed and registered when Powerpoint is installed. COM and .NET are totally different technologies. To use COM types from your .NET application, you don't use COM type directly but a special interop .NET assembly. This assembly doesn't contain any PPT functionality, it's just a wrapper that servers as a bridge between your .NET application and a COM type. An interop assembly does all the hard work for you and defines .NET types (from COM types) that you can use as other .NET classes, for example powerpoint.Application.

The interop assembly is just a normal .NET assembly. You can reference it as other .NET references (Embed Interop Types = false). In this case you need to distribute the interop DLL with your application. If you set Embed Interop Types = true, then the interop assembly is compiled and embedded directly to your application assembly. Moreover, only types and functions that are really used are embedded. So using this option has the advantage of optimized and single assembly.

But still, even when embedded, the interop info is just a wrapper over real COM type that must be installed on client machine. If it's not, you get the error.
See more details at https://msdn.microsoft.com/en-us/library/xwzy44e4.aspx

Your option is to force the client to install PPT or avoid Microsoft.Office.Interop.PowerPoint and use some third-party PPT library that you can distribute with your application.

Why does embed interop types need to be set to false for SAPbobsCOM.dll in SAP b1 project?

I have been making SAP B1 AddOns for years and have never set Embed Interop Types to false. I do not think you have to do this. This is for addons added using the .ard file and programs running outside of B1.
This applies also to SAPbouiCom.dll.

I package my addons within Visual Studio using the B1DESetup_B192 tool and there is no such requirement as you stated above. See image below.

Where and How to set 'Embed Interop Types' false in visual studio

There is no need to use the Embed Interop Types property for Office interops libs.

Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.

If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article in MSDN.

You may consider using the Open XML SDK, see Welcome to the Open XML SDK 2.5 for Office for more information. Or just find any third-party components designed for the server-side execution.

safety of modifying Embed Interop Types reference setting (and an audio player)

You need to ignore the safety argument, it is just nonsense. The issue is that the Embed Interop Type feature requires types to have a one-to-one match with the interface in the COM server. They must have a [Guid] attribute that matches. That attribute allows them to declare that types loaded from different assemblies are compatible, even though they came from different assemblies. The match on the Guid is the key.

Which is a problem with the classes whose name end in "Class". They are 'fake' classes, synthesized from the real COM coclasses. It solves a problem with .NET not supporting multiple inheritance. Since they are auto-generated, their [Guid] doesn't match a CLSID in the COM type library and the type cannot be embedded because their is no way to verify type equivalence.

You can very often avoid the multiple inheritance problem and just create an instance of the coclass without the "Class" postfix. Certainly in this case:

        var player = new QuartzTypeLib.FilgraphManager();
        player.RenderFile(@"c:\temp\test.avi");

Compiles and runs, doesn't play. But that's a different problem, you should use Windows Media Player instead. Add a reference from the COM tab.

Disabling EIT is not really an issue, you just get an interop.dll file in your build directory that you need to deploy on the user machine. EIT was really designed to solve a problem with PIAs (Primary Interop Assemblies), a problem that you don't have here since you are not exposing the native COM interfaces to any other assemblies.

missing Embed Interop Type property

You need to go to the Dll in the References, Right Click and Properites. It is there, not on the properties of your project

What does reference was created to embedded interop assembly mean?

Per the MSDN:

"You have added a reference to an assembly (assembly1) that has the Embed Interop Types property set to True. This instructs the compiler to embed interop type information from that assembly. However, the compiler cannot embed interop type information from that assembly because another assembly that you have referenced (assembly2) also references that assembly (assembly1) and has the Embed Interop Types property set to False."

To address this warning

To embed interop type information for both assemblies, set the Embed Interop Types property on all references to assembly1 to True.

This means you must change 'Embed Interop Types=true' on System.Windows.Forms.dll

or

To remove the warning, you can set the Embed Interop Types property of assembly1 to False. In this case, interop type information is provided by a primary interop assembly (PIA).

Embedding an Interop or Not?

The article is outdated, it was written before .NET 4.0 was released. The first version (along with VS2010) that started to support the "Embed Interop Types" feature. You always favor the default of True. Instead of having the COM interop types stored in an xyz.Interop.dll assembly they now get copied into the assembly that uses them. Only the actual types you use. So entirely normal you don't see them in the build directory, you don't need them anymore.

It actually solves a much a bigger problem, getting PIAs (Primary Interop Assemblies) deployed to a machine. Relevant above all to programs that interop with Office. Not usually an issue when you interop with WMP since you won't expose any WMP types from your own assemblies to be used by other apps. If you would then you have no problem :)

Visual Basic PowerPack is a normal .NET assembly, not a COM interop assembly, so can't be treated the same way. "Access OLEDB" is too vague, rely on the default.

The underlying feature is "type equivalence", a structural CLR improvement that can help types from different assemblies to be considered identical. If CLR architecture interests you then you want to watch this video.

---

Related Topics