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:
C:\MyApp\TheAssembly\MyClass.cs(823,57):
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.
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
Hope this helps.
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.
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; }
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With