Why is there a RegisterMceApp.dll and a RegisterMceApp.exe?

  • Article

One of the things I noticed when I first started looking into the Media Center SDK to try to build a Media Center add-in was that the SDK includes a file named RegisterMceApp.dll that is designed to be used in MSI-based setup packages that install Media Center add-ins. I also noticed that the core Media Center product includes a file named RegisterMceApp.exe that we tell customers to use to register add-ins. The natural question that came to my mind was - why do we have a DLL and an EXE that appear to do the same thing according to our own documentation.

After talking to the developer who originally wrote RegisterMceApp.dll and looking at the source code, I found that RegisterMceApp.dll is essentially a DLL-based wrapper around the same API calls used in RegisterMceApp.exe. There are 2 key behavioral differences in the DLL:

  1. The DLL uses MSI API calls to determine if the setup being run is a per-user or per-machine installation and runs the per-user or per-machine version of the RegisterMceApp APIs. Because it uses MSI APIs, the DLL can only be run as a custom action inside an MSI-based setup and not via a stand-alone non-MSI process
  2. The DLL ignores the return codes received by the RegisterMceApp APIs and returns 0 in all cases. I presume that this is done to avoid the problems presented when trying to use RegisterMceApp.exe in a setup package that I described in this blog post.

The interesting thing about these behavioral differences is that they can be handled by using RegisterMceApp.exe and correctly authoring the logic in an MSI setup, which would eliminate the need to have a separate DLL.

To address the first issue, you can author separate custom actions to run RegisterMceApp.exe in per-user mode and in per-machine mode and then condition them to check the ALLUSERS property and run at the appropriate times.

To address the second issue, you can author a custom action to unregister the add-in prior to trying to register it. This gives you the added benefit of being able to correctly fail and roll back your add-in setup if registration fails (which is impossible with the DLL because it always returns a success error code).

Authoring the custom actions in the manner I describe above is relatively straightforward in general, but it doesn't appear to be easy to accomplish in the UI of a Visual Studio setup/deployment project. I am working on an example MSI package using WiX to demonstrate how to create a well-behaving Media Center add-in, and I will be using the strategies that I describe above in that package. Stay tuned for more info....