1

If you add a reference to an interop assembly in Visual Studio, you can set 'Embed Interop Types' to true (though that might be the default). If you do, the types for the interop interfaces become 'dynamic' and no reference to the interop assembly exists in the manifest. However, when you move to using a PackageReference for the interop assembly the default for 'Embed Interop Types' is false and setting it to true is very difficult. This kind of works:

https://github.com/NuGet/Samples/blob/main/NuGet.Samples.Interop/README.md

It will allow you to set the EmbedInteropTypes to true and fix any compiler errors you may have run into due to EmbedInteropTypes being false. It will also not reference the interop assembly in the manifest. However, the VS editor will not treat the interface variables as 'dynamic' and thus will show the method calls and property gets/sets as if they are errors, ie. red squigglies.

This is similar, if not the same question as:

where is the Embed Interop Property in VS?

but as my account is new I wasn't able to comment and answer that post. Plus I'm hoping someone can chime in on whether there's more of a complete fix for this. I've noticed this in both VS 2019 and VS 2022.

I searched for ways to set 'Embed Interop Types' for a PackageReference but I don't see any way to do that other than the link I show above. And that only partially works.

squidward
  • 11
  • 1
  • It stands to reason that the Nuget team tried to solve this problem. But deploying COM interop assemblies as a package is fundamentally a bad practice. Problem is that Nuget cannot do anything to ensure that the COM server is properly installed and the interop assembly has the correct version. Big deal, COM has a strong DLL Hell problem. The server must be installed to debug and run an app, and when that's done then you can always get the correct interop assembly, simply by selecting the server from the Add Project Reference > COM tab. Bigger reason why this is still possible in .NET Core – Hans Passant Jan 28 '23 at 14:14
  • Actually when you embed the interop types it uses late binding (IDispatch) and thus you're less prone to versioning issues. – squidward Jan 28 '23 at 21:22
  • That is not correct. Embedding only affects the location of the metadata, embedding it in the project's assembly. And thus bypassing the need to deploy the interop assembly. – Hans Passant Jan 28 '23 at 21:47
  • @Hans, are you sure about that? This article, https://learn.microsoft.com/en-us/dotnet/standard/assembly/embed-types-visual-studio, indicates embedding the types allows for loose coupling and version independence. – squidward Jan 29 '23 at 16:35
  • Very sure. The first paragraph of that article is nonsense, rest is okay. If you want to use late binding (use *dynamic*) then you don't need any interop types at all. It is more tolerant of version mismatches, but not a panacea. You can't expect, say, a change like an extra parameter to a method to come to a good end. – Hans Passant Jan 29 '23 at 16:40
  • @Hans, thanks. However, I was pretty sure, though could be remembering wrong, that the type changed from some concrete type defined in the interop assembly to dynamic when I select "true" for embed interop types. – squidward Jan 29 '23 at 20:34
  • @Hans, we can't use dynamic for everything, correct. Yeah, invoking the methods and properties, but for new'ing type I assume some progId or GUID is needed and pulled from the interop assembly. – squidward Jan 29 '23 at 20:36

0 Answers0