Cannot embed interop types in VS2010

When you are working with Word or Excel, you cannot embed the interop type "..." in VS2010, instead, use the workaround for the applicable interface

Asked the mother, the solution is the same: Select the DLL that was introduced in the project, right-click, select Properties, set the "Embed interop type" to false. After the problem is solved easily, there should be a lot of people who are struggling with this "embed interop type" What is the meaning of it? Let me slow down the road. (If you don't have much time, look directly at the Red font section)

As far as software is concerned, interoperability-the term used to describe different programs (programs) uses the same set of interchange formats (Exchange formats) to Exchange data, read and write the same file format formats) and the ability to use the same protocol (protocols). (This definition of interoperability does not expect the ability to perform the same binary code <binary code> on different processor platforms <processor platforms >. The lack of interoperability may be a consequence of the lack of attention to standardization (standardization) during programming. In fact, interoperability is not a matter of course in the computing world, which is not a standard-based part.

According to the International standard ISO/IEC 2382-01 Information Technology Glossary, the basic terminology (ISO/IEC 2382-01, Information technology vocabulary, fundamental Terms), the interoperability is defined as follows: " The ability to communicate, execute programs, or transmit data between these functional units with little or no user knowledge of the unique characteristics of various functional units ". The above two paragraphs are Wikipedia's interpretation of "interoperability," which gives us a basic concept of "embedding interop Types".

Then let's talk about "embedding interop types," which is excerpted from MSDN Magazine. may give us some enlightenment and understanding.

Embedding COM Interop Types

This is more like a C # compiler feature than a C # language feature, but you can now use COM interop assemblies without requiring that the assembly must exist at run time. The goal is to mitigate the burden of deploying COM Interop assemblies with your application.

When COM Interop is introduced in the original version of the. NET Framework, the concept of the primary interop assembly (PIA) is established. This concept was introduced to address the challenge of sharing COM objects between components. For instance: If you have some different interop assemblies that define an Excel Worksheet, we cannot share these Worksheet between components because they have different. NET types. The PIA solves this problem by only having one time: all clients use it, so. NET types are always matched.

Although PIA is theoretically a good idea, it is proving to be a big hassle in real-world deployments because it has only one copy, and multiple applications may try to install or uninstall it. And because the PIA is usually big, things are more complicated. Office does not deploy them in the default Office installation mode, and users can easily bypass this assembly system by simply creating their own interop assemblies using TLBIMP.

So now, in order to reverse this situation, two things have happened:

For two COM interop types that have the same structure and share the same recognition characteristics (name, GUID, and so on), the runtime can intelligently treat it as a. NET type. The C # compiler takes advantage of this by reproducing the interop types directly in your own assembly at compile time, and therefore no longer requires that the interop assembly be present at run time.

Due to space constraints, I have to omit some of the details, but even if you don't know the information, you should be able to use this feature without any obstacles, just like dynamic functionality. You tell the compiler to embed an interop type into Visual Studio for you by setting the embedded Interop Type property on the reference to true.

Because the C # team expects this approach to be the preferred method for referencing COM assemblies, by default, Visual Studio sets this property to True for any new interop references that are added to a C # project. If you use the command-line compiler (csc.exe) to compile your code, use the/L switch instead of the/R switch to embed the interop types in the interop assemblies that you must reference.

All of the features described in this article can generate a lot of discussion, and each topic deserves to be discussed. I omitted a lot of details, and many details were just around the area. See here, we probably have a clear understanding, then let me do a few summary of it (the lack of welcome to add).

1. Embedding in the "Embed Interop Type" is the introduction, import, similar to the role of include in C # in Using,c, to tell the compiler whether to introduce an interop type.

2. "Interop Type" actually refers to the Assembly of a series of COM components, which is a library file in the public runtime, similar to a compiled class, interface, and so on.

3. The Embed interop type is set to true, in effect, the assembly that compiles only user code without introducing an interop set (which discards COM assemblies at compile time).

When set to False, it is actually necessary to get the type information of the COM type from the interop assembly.

I do not know the people understand no, I am a little understand ...

Cannot embed interop types in VS2010