0

I'm writing a program that is using the WMPLib Reference as part of the project.

My question is, I noticed on MSDN documentation the following:

https://msdn.microsoft.com/en-us/library/windows/desktop/dd564585(v=vs.85).aspx Distributing Your Application

When you distribute your application, be sure to install AxInterop.WMPLib.dll and Interop.WMPLib.dll in the application folder. You will also need to make sure that the required Windows Media Player version is installed on the user's computer.

When I compile my project, I noticed that in the executable folder there is no mention of the WMPLib.dll or the Interop.WMPLib.dll, even though it is properly referenced in my code. That is until I change the option "Embed Interop Type" from True to False. Then when I compile the program, I noticed that the file `Interop.WMPLib.dll" is then made available in the base folder along with the executable that I just compiled.

enter image description here

Is this normal behavior for the file to be only be created in this instance? If I'm planning on distributing this application to other Windows PCs, should I leave the "Embed Interop Type" to false? Additionally should I do this to all my references like the Visual Basic PowerPack? What about the Windows Pack that I used to be able to connect to an Access DB, is there something I need to do there?

Community
  • 1
  • 1
Paul Williams
  • 1,554
  • 7
  • 40
  • 75

1 Answers1

2

The article is outdated, it was written before .NET 4.0 was released. The first version (along with VS2010) that started to support the "Embed Interop Types" feature. You always favor the default of True. Instead of having the COM interop types stored in an xyz.Interop.dll assembly they now get copied into the assembly that uses them. Only the actual types you use. So entirely normal you don't see them in the build directory, you don't need them anymore.

It actually solves a much a bigger problem, getting PIAs (Primary Interop Assemblies) deployed to a machine. Relevant above all to programs that interop with Office. Not usually an issue when you interop with WMP since you won't expose any WMP types from your own assemblies to be used by other apps. If you would then you have no problem :)

Visual Basic PowerPack is a normal .NET assembly, not a COM interop assembly, so can't be treated the same way. "Access OLEDB" is too vague, rely on the default.

The underlying feature is "type equivalence", a structural CLR improvement that can help types from different assemblies to be considered identical. If CLR architecture interests you then you want to watch this video.

Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • To give additional information to the OLEDB: In order to get my VB.NET application to read from the AccessDB. My question was asking if I needed to do anything to the application for a PC that doesn't have the same pack – Paul Williams Jan 29 '16 at 21:17
  • Specifically, do I have to anything special with the redistributable linked here in this answer: http://stackoverflow.com/a/27259078/692250 . I want to say no, but I'm not sure. – Paul Williams Jan 29 '16 at 21:30
  • The System.Data.OleDb namespace is built into the framework, the ADO data provider for Access is preinstalled on the operating system. Maybe you are using ACE, no idea. Just click the Ask Question button to document your question better although it is surely already answered somewhere. – Hans Passant Jan 29 '16 at 21:30
  • Yeah I kind of thought that would be spammy if I submitted multiple "semi-related" questions. – Paul Williams Jan 29 '16 at 21:31
  • Yes, it is complete PITA. – Hans Passant Jan 29 '16 at 21:31