Home » excel » excel – Are we unable to use Interop objects in generic objects in .NET 4.0?

excel – Are we unable to use Interop objects in generic objects in .NET 4.0?

Posted by: admin April 4, 2020 Leave a comment


I’m working in VS 2010 and working on upgrading our application to .NET 4. The application is built with Excel as the base and we want to take advantage of some of the improvements to .NET for using Excel. But I ran across a strange error that seems to be caused by using an Excel Interop object in a generic dictionary. Here is the error that was generated:

error CS1769: Type 'MyApp\OtherAssemply.IMyController.SheetReports' from assembly 'c:\MyApp\OtherAssemply.\bin\Debug\OtherAssembly.dll' 
 cannot be used across assembly boundaries because it has a generic type 
 parameter that is an embedded interop type.

Here’s the actual property that has the issue:

Dictionary<Excel.Worksheet, IReportSheet> SheetReports { get;}

Are we unable to use Interop objects in generic objects? If so, this is a serious limitation in .NET 4.0. I tried setting the Embed Interop property to false, but that didn’t seem to change anything. Please let me know if there is any way around this.

How to&Answers:

A new feature of VS2010 is to embed the interop types into the assembly instead of using external interop assemblies.

The benefit is that you don’t need to distribute the interop assemblies.

The drawback is that each assembly get its own set of the interop types.

Since the type “Excel.Worksheet” is now internal to your assembly, other assemblies can’t use a generic type based on it (which is what the error message says)

You get a similar error if you do

internal class X { }
public class Y {
    public List<X> l;

I have not used VS2010 but I’m sure there must be an option somewhere where you can turn off the embedded interop types.


Adrian gave almost a correct answer but there is a better way of dealing with this error. Do not turn off Embed Interop Types but use a generic interface instead:

IDictionary<Excel.Worksheet, IReportSheet> SheetReports { get;} 

CLR 4.0 introduced a concept of Type Equivalence. If we were to slightly simplify what this means then we could say that CLR 4.0 treats two identically named interface types, with identical Guid attributes as if it is the same type. Notices that type equivalence is built very deeply into the system and makes working with equivalent types as if it was one type. Few examples;
1. You can use reflection to invoke an interface method on an object implementing an equivalent interface.
2. Instances of generic interfaces parameterized on equivalent interfaces are also considered to be equivalent.

C# and VB compilers take advantage of this feature to implememnt “Embed Interop Types” feature.

Now to the exceptions:
1. The reference comparisons between equivalent interfaces System.Type’s will fail since these are still two different types in the type system:

typeOfWorkbookFromAssemblyA.Equals(typeOfWorkbookFromAssemblyB) == false

but there is a new API Type.IsEquivalentTo

typeOfWorkbookFromA.IsEquivalentTo(typeOfWorkbookFromB) == true
  1. Two instances of the same generic class parameterized on equivalent interfaces are not considered to be equivalent.

Hope this helps.


I got into the similar issue with Outlook AddIn and the answer provided by Misha works like a charm.
I had a property

public List<Microsoft.Office.Interop.Outlook.Attachment> Attachments { get; set; }

and simple change of List to interface IList solved the problem

public IList<Microsoft.Office.Interop.Outlook.Attachment> Attachments { get; set; }