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; }