Create WiX installer for ActiveX Object

2
votes

I have used heat to generate a file with the registry entries, and in visual studio have created a wix project. I have tried including the fragment directly in product.wxs, as well as referencing it as a component group. When I execute the installer nothing happens. To test the ActiveX object was added properly, in Internet Explorer, new ActiveXObject('<prog ID>') should work but it does not. I'm guessing the registry keys aren't enough. How do I add the .dll created by the ActiveX object and ensure that Internet Explorer can locate the ActiveXObject?

From my comment: Here is an example repo of what I am trying to do. I created a class library with a COM visible function. This has a ProgId with "ActiveXExample" and should be able to be installed to the machine with the ActiveXExampleInstaller .msi created by WiX. I run the installer and see no registry keys added or the files added. I am pretty sure it's a problem with the directory structure but I do not really understand how to add files still. https://github.com/SvenWritesCode/ActiveXExample

1
visual-studiowixwindows-installeractivex
Any updates on this? I am sort of not too happy about having suggested marking core COM objects safe for scripting. It really is something that has to be run by security guys. IE11 is in full lockdown for good reason... - Stein Åsmul
It may just be an x86 vs x64 issue. I'm oversimplifying, but if you use 32-bit IE, you must register your COM object (ActiveX = COM) into the 32-bit registry, if you use 64-bit IE, you must register your COM object into the 64-bit registry, and if you want to use both, you must register in both registries. => It may simply mean you have to build two MSIs: one for x86 setup and one for x64. - Simon Mourier
64-bit MSI files can install both 32 and 64 bit components, but such a package can not run on an x86 machine. Hence you can build one MSI if you never need to install on a REAL x86 machine. Note that WiX has some issues with x64 COM files (unless it has been fixed - see links below regarding WiX and COM registration). - Stein Åsmul
@SteinÅsmul The application is currently for a local intranet with no access to the internet so even though marking the FileSystemObject as safe would probably work, but was still too much of a security risk. My thought (correct me if i'm wrong) was creating my own Active X object with the same functionality and then being able to install it onto the client computer, would be a better idea. - Sven Writes Code
I suppose that might work, but I would then use VB6 or C++ to make a real COM object instead of a .NET assembly registered for COM Interop? I am no expert at that technology, and it is basically obsolete as I have repeated too many times :-). - Stein Åsmul

1 Answers

2
votes

Summary: 1) There might be restrictions in the IE security options that prevent your ActiveX control from running at all. 2) Further there might be problems with the registration of the control outright.

  • Below are some resources to help you debug.
  • Is the ActiveX control digitally signed?
  • Can you instantiate the control outside of IE?
  • Is this a 64-bit binary?

Please comment below and maybe provide a sample on github.com? Will check back.

IE: Active X in Internet Explorer tends to be shut off these days?

  • Installing ActiveX controls for browser access used to entail invoking the installation from a web server and downloading a digitally signed installer from there.

  • The process of installing signed ActiveX controls from a web-site is described here: Packaging ActiveX Controls with Wix MSI (please do read this linked answer - important).

  • Looking at Internet Explorer on a Windows 10 test box there looks to be a significant number of restrictions enforced. Here is an illustration (not actual windows 10 dialogs):

    ActiveX

COM Registration: COM registration in and of itself with WiX is a bit clunky compared to many other tools (commercial). Here is a writeup on some issues: Registering COM EXE with WIX. Note that 64-bit COM files are not properly handled by WiX (unless it has been fixed recently).

Heat.exe: It sounds like you have already used it, but running heat.exe to get COM registration information for the file can be done like this:

heat.exe file MyCOMDll.dll -out MyCOMDll.wxs

The MyCOMDll.wxs file must then be incorporated into your main WiX source somehow. I just extract the contents I need manually and inject into the main source. This takes some experience, but isn't that hard. If there are problems, maybe your sources can be put on github.com perhaps? So we can take a look? It is always hard to figure out things without the source.

Links: