10
Vote

Set "Embed Interop Types" to False for EnvDTE in NugGet.VisualStudio.dll

description

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)

See:
on why this COM-inspired feature should not be considered a general-purpose versioning story for nuget, since it breaks the typical developer flow for VSX authors.

comments

Haacked wrote Mar 22, 2011 at 9:36 PM

If anyone wants to submit a well tested pull request, we'll consider accepting it.

dcazzulino wrote Apr 20, 2011 at 1:04 PM

Sent! :)

Haacked wrote May 27, 2011 at 5:57 PM

We commented on your pull request and are still waiting for your fixes.

RanjiniM wrote Feb 22, 2013 at 7:55 PM

http://blog.nuget.org/20120926/invoking-nuget-services-from-inside-visual-studio.html. See the post for details on why it should be true.

** Closed by RanjiniM 02/22/2013 12:55PM

dcazzulino wrote Feb 23, 2013 at 3:04 AM

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.

dcazzulino wrote Feb 23, 2013 at 3:05 AM

From my last comment:

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.

dotnetjunky wrote Feb 23, 2013 at 5:01 PM

I think your second comment is a duplicate of the first.

dotnetjunky wrote Feb 23, 2013 at 7:28 PM

I will talk to the VS team to seek their guidance on this. Thanks for providing the links.

dcazzulino wrote Feb 24, 2013 at 4:24 AM

Thanks, that would be awesome! It should be enlightening for anyone doing VSX work and shipping utilities/runtimes for use by other VSIXes...

dotnetjunky wrote Feb 26, 2013 at 6:29 PM

I gave this a try, but I kept getting a build error. So I'll have to postpone this to 2.4 for now.

dcazzulino, if you want to take a crack at it, feel free to go for it. I pushed my work to the 'nopia' branch. It builds fine in a machine with VS2012 installed, but failed with a machine with only VS2010.

dcazzulino wrote Mar 13, 2013 at 1:21 AM

What did the VS guys say?

lmorris wrote May 18 at 2:42 PM

Has this been resolved? Are there any workarounds? This is causing a lot of problems debugging my VSPackage.
Thanks