2

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

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
Namaskar
  • 2,114
  • 1
  • 15
  • 29
  • 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 Nov 09 '19 at 17:43
  • 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 Nov 10 '19 at 10:00
  • 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 Nov 10 '19 at 13:12
  • @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. – Namaskar Nov 10 '19 at 19:18
  • 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 Nov 10 '19 at 20:11
  • @SteinÅsmul - COM is *not* obsolete. It's been used everywhere in Windows, and .NET is fine for writing "real COM objects". VB6 is indeed obsolete. – Simon Mourier Nov 11 '19 at 07:15
  • Yes, we will struggle with COM for a long time - especially in corporate settings :-). As a deployment guy I have never liked COM (too many things that can break via the registry), but it is a pervasive technology indeed that many have a lot invested in. I was merely thinking about the easiest way to make a COM object that IE could consume. – Stein Åsmul Nov 11 '19 at 07:19

1 Answers1

2

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:

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • 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 – Namaskar Nov 08 '19 at 19:11
  • What is the scenario for this? You want to run a .NET assembly as an ActiveX component in IE? I have honestly not done that before. I would think you need the [`Regasm.exe`](https://learn.microsoft.com/en-us/dotnet/framework/tools/regasm-exe-assembly-registration-tool) tool to register a .NET assembly as callable from COM? Is that how you generated all that COM registry stuff? Not quite clear. – Stein Åsmul Nov 08 '19 at 20:32
  • Old classics: [COM => .NET](https://learn.microsoft.com/en-us/previous-versions/dotnet/articles/ms973800(v=msdn.10)) and [.NET => COM](https://learn.microsoft.com/en-us/previous-versions/dotnet/articles/ms973802(v=msdn.10)). Just for reference. And [one more classic on threading](https://stackoverflow.com/questions/2092523/how-to-mark-net-objects-exposed-to-com-interop-as-single-threaded). – Stein Åsmul Nov 08 '19 at 20:35
  • The end goal is to be able to access the file system on the a client's computer through the browser. I narrowed into ActiveX as an easy(tm) way to achieve that functionality. The project is written in c# so that's what I'm using to create the class library. To answer your other question, I generated the COM registry stuff by running heat on the `ActiveXExample.dll` and copying the `fragment` output into the `Product.wxs`. This may be a classic XY problem and am open to suggestions. – Namaskar Nov 08 '19 at 20:38
  • ActiveX is pretty old and heavily disabled in IE11, not sure that would be a good option for you long term? What does the file access involve? Retrieving files for upload somewhere or just viewing? Maybe you can add some more details to your question? There are those .NET assemblies that expose a COM interface marked safe for scripting. [Here someone has marked FileSystemObject safe for scripting](https://stackoverflow.com/a/41803627/129130). Danger close I dare say. Not sure if it works. Not sure if anyone should ever try it :-). Virtual? It can ruin computers entirely. Local intranet zone? – Stein Åsmul Nov 09 '19 at 03:15