Daniel Cazzulino's Blog

Go Back to
kzu′s Latest post

Check your Embed Interop Types flag when doing Visual Studio extensibility work

In case you didn’t notice, VS2010 adds a new property to assembly references in the properties window: Embed Interop Types:


This property was introduced as a way to overcome the pain of deploying Primary Interop Assemblies. Read that blog post, it will help understand why you DON’T need it when doing VS extensibility (VSX) work.

It’s generally advisable when doing VSX development NOT to use Embed Interop Types, which is a feature intended mostly for office PIA scenarios where the PIA assemblies are HUGE and had to be shipped with your app. This is NEVER the case with VSX authoring. All interop assemblies you reference (EnvDTE, VS.Shell, etc.) are ALWAYS already there in the users’ machine, and you NEVER need to distribute them. So embedding those types only increases your assembly size without a single benefit to you (the extension developer/author).

But on the other hand, it confuses the VS debugger the hell out. If you are debugging some VS automation code and want to issue a command via the Immediate window or the Quick Watch to (say) count how many projects are there in the solution, you’d enter something like this: dte.Solution.Projects.OfType<EnvDTE.Project>().Count(). When you do, you will get this seemingly weird error:

Embedded interop type ‘EnvDTE.Project’ is defined in both ‘EnvDTE.dll’ and ‘NuGet.VisualStudio.dll’. Some operations on objects of this type are not supported while debugging. Consider casting this object to type ‘dynamic’ when debugging or building with the ‘Embed Interop Types’ property set to false.

But now that you know what that property is for, you probably guessed why it’s happening: the debugger doesn’t know WHICH EnvDTE you are referring two, because there are TWO in the AppDomain, one in the VS built-in EnvDTE.dll assembly, and one in NuGet.VisualStudio.dll assembly in this case (as reported), which is of course contains EnvDTE types as they are embedded!!!

So, it makes it painful for everybody doing VS extensibility work, for no gain whatsoever.


Next time you add an assembly reference to a VSIX project, please go and check that property, as the default behavior kick is to embed the types.





  1. Thanks for sharing this. but wondering how to vsts save these reference property info because I need to check the EmbedInteropTypes=True in source control but found a hard time to locate which file contains this setting.

  2. It’s in the node in the msbuild project file.

  3. hi, I can not found Embed Interop Type
    I am using VS2010, project target to .net3.5

  4. I had an endless search for a solution to change the Embed Interop Type flag and could not believe the answer to this operation was so simple. Thanks

  5. Hey, thanks for this , but, what if the Embed Interop types property is disabled and maintained to true ? how can i change that?

    • Handeen, you can always change it via the csproj, like:

      <Reference Include=”Accessibility”>

  6. Daniel, you saved my day thank you !

  7. I have set the Embed Interop property to false on all my project references, but still get the Error. Are there other things to try?

  8. [...] Check your Embed Interop Types fall when doing Visual Studio extensibility work [...]

  9. This article is old and not correct. Please don’t follow its guidance. The VS SDK actually ships several reference assemblies that are NOT included in the standard VS product. So you SHOULD leave EmbedInteropTypes=true for these assemblies or else your extensions will fail to load on other people’s machines that don’t have the SDK installed.