Embedding the types only makes the assembly bigger for no benefit.
And it does screw up debugging for anyone doing VS extensibility, where you start getting errors like this:
soln.Projects.OfType<EnvDTE.Project>()
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.
(here I was trying to inspect the current solution in a quick watch window)
Comments: I'll try to give it another try to fix this. The blog post does not answer why it should be true. It only says that it should, but for the wrong reasons. I could just as easily point to my own blog post on why it should NOT be true (http://blogs.clariusconsulting.net/kzu/check-your-embed-interop-types-flag-when-doing-visual-studio-extensibility-work/). I'll just re-link here what is said in the actual C# compiler implementer of the feature: http://blogs.msdn.com/b/samng/archive/2010/01/24/the-pain-of-deploying-primary-interop-assemblies.aspx. You can read pretty much all of the entries from http://blogs.msdn.com/b/mshneer/ from around VS2010 release dates to also learn more about the background. You can even see Anders slides from PDC2008 where this feature is a bullet under "Improved COM Interoperability": http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/TL16.pptx The entire point of the "embed interop types" was to come up with a solution to the PIA problem. You seem to be trying to use it as a general versioning strategy, which is NOT needed in .NET managed assemblies. It was invented for COM, and I don't see much COM code in NuGet ;). This keeps being a pretty annoying "feature" especially since VSX leveraging nuget VS APIs is far from a core usage scenario (unlike general VSX work is). Again, this makes it very painful to debug and do immediate window work with *any* kind of VSX projects while nuget is installed. This is made only worse now that VS2012 bundles it and you have to explicitly remove it to be able to debug efficiently any VSX extension. I know VS runtime binding redirect story is not ideal, especially for extensions authors (i.e. we have no way of contributing binding redirects to the IDE). But the solution is not to hack around that by "leveraging" a technology invented for something else that causes further pain to totally unrelated (and unaware) developers. The solution should be (I think) to sit down with VS guys and get them to expose a way for vsixes to contribute binding redirects to the devenv.exe.config (i.e. similar to the way you can contribute fragments of registry settings via a .pkgdef file?). In the meantime, you should version NuGet interop assemblies the same way VS does it: append a version # to the assembly file, continue shipping the older versions which just redirect to the new versions (maybe type forwarding could be used?, see http://msdn.microsoft.com/en-us/library/ms404275.aspx), and have people rely on the presence of the assembly they bind to at compile time, at run time (i.e. NuGet itself ships these assemblies, always). For these reasons, I do not consider the issue to be appropriately resolved.
And it does screw up debugging for anyone doing VS extensibility, where you start getting errors like this:
soln.Projects.OfType<EnvDTE.Project>()
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.
(here I was trying to inspect the current solution in a quick watch window)
Comments: I'll try to give it another try to fix this. The blog post does not answer why it should be true. It only says that it should, but for the wrong reasons. I could just as easily point to my own blog post on why it should NOT be true (http://blogs.clariusconsulting.net/kzu/check-your-embed-interop-types-flag-when-doing-visual-studio-extensibility-work/). I'll just re-link here what is said in the actual C# compiler implementer of the feature: http://blogs.msdn.com/b/samng/archive/2010/01/24/the-pain-of-deploying-primary-interop-assemblies.aspx. You can read pretty much all of the entries from http://blogs.msdn.com/b/mshneer/ from around VS2010 release dates to also learn more about the background. You can even see Anders slides from PDC2008 where this feature is a bullet under "Improved COM Interoperability": http://mschnlnine.vo.llnwd.net/d1/pdc08/PPTX/TL16.pptx The entire point of the "embed interop types" was to come up with a solution to the PIA problem. You seem to be trying to use it as a general versioning strategy, which is NOT needed in .NET managed assemblies. It was invented for COM, and I don't see much COM code in NuGet ;). This keeps being a pretty annoying "feature" especially since VSX leveraging nuget VS APIs is far from a core usage scenario (unlike general VSX work is). Again, this makes it very painful to debug and do immediate window work with *any* kind of VSX projects while nuget is installed. This is made only worse now that VS2012 bundles it and you have to explicitly remove it to be able to debug efficiently any VSX extension. I know VS runtime binding redirect story is not ideal, especially for extensions authors (i.e. we have no way of contributing binding redirects to the IDE). But the solution is not to hack around that by "leveraging" a technology invented for something else that causes further pain to totally unrelated (and unaware) developers. The solution should be (I think) to sit down with VS guys and get them to expose a way for vsixes to contribute binding redirects to the devenv.exe.config (i.e. similar to the way you can contribute fragments of registry settings via a .pkgdef file?). In the meantime, you should version NuGet interop assemblies the same way VS does it: append a version # to the assembly file, continue shipping the older versions which just redirect to the new versions (maybe type forwarding could be used?, see http://msdn.microsoft.com/en-us/library/ms404275.aspx), and have people rely on the presence of the assembly they bind to at compile time, at run time (i.e. NuGet itself ships these assemblies, always). For these reasons, I do not consider the issue to be appropriately resolved.