Registering DLLs in COM with WiX for creating an MSI installation package for a Kofax Custom Panel

I was working on a project recently for a customer that was upgrading their Kofax versions and making some enhancements to a custom Kofax panel that we had written for them some time ago. Like any good developer, I migrated the code for the custom panel to the latest version of Visual Studio I had, (in this case, Visual Studio 2012). I had finished development and was discussing installation when the customer requested an MSI package to install the custom panel. Unbeknownst to me, Visual Studio 2012 had dropped their support for the easy, drag and drop, built in set up and deployment project to create MSI’s.

In doing some research, I found many developers had migrated to using the open source WiX product to create MSI packages, ( One can download WiX and integrate it directly into Visual Studio. Everything was fairly straight forward on following their tutorials except for one snag: in order to get the custom Kofax panel to install correctly, I had to register the custom DLLs as COM Components, not in the GAC. After a lot of head scratching, I finally figured out that I could use Heat (one of the WiX tools) to create a registry file of the DLLs to include in my WiX set up project. You can find out more about Heat here: After the file was generated I was able to take the output of the Heat generated file and include it in my WiX install project to register the necessary DLLs. To do this, I followed these steps: Continue reading

No COM object available in Component Services snap-in

I have been working with Windows Server 2008 R2 64bit and Windows 7 64bit a lot lately. In doing so, I have noticed a problem when installing a specific product that requires a COM server. When I launch the MMC to access the Component Services snap-in, I find the COM object for this software doesn’t exist. I have double-checked this until I was blue in the face. Where is that COM object? I have properly installed and can use the product, but it simply doesn’t exist in the DCOM config portion of Component Services. Like all good IT professionals, I turn to Google. (The link below further explains the problem and solution for this.) Apparently, Windows removed a process called Registry Reflection from Windows 7 and Windows Server 2008 R2 OS’s. Registry Reflection was a process that would replicate registry keys between both 32bit and 64bit registry views. Since this was removed, all registered 32bit COM objects are only available in the 32bit version of the MMC. Once you access those objects through the 32bit MMC they will replicate and become available to you in the 64bit version. To access the 32bit version of the MMC, run this command “mmc -32” from the command line.

Read more about this solution by visiting Maarten’s blog – My COM server is gone from Component Services (DCOMCNFG)

Andrew D. Skovran
Support Engineer
ImageSource, Inc.

Leveraging ECM Software APIs

System Engineers must to be able to choose from a menu of technologies in order to solve ECM business problems. While ECM software vendors often strive to provide a complete set of tools for any anticipated business challenge, in reality, technology advances almost always outpace product release cycles.

Service Oriented Architecture (SOA), Simple Object Access Protocol (SOAP), Extensible Markup Language (XML), and many other similar, and often interoperable, technologies have and are being developed in an effort to provide the ability to glue disparate systems together using  published, standards-based mechanisms. While extremely useful, these technologies suffer from some of the same issues as vendor software such versioning, bloat, vendor specificity, and so on.

As an engineer in the field, it’s critical to choose best-of-breed products that solve a core purpose extremely well, then extend the product with other current technologies until a complete solution emerges. Application Programming Interfaces (APIs), whether COM, Web Service, or something else is what makes this extensibility possible. The most useful ECM products provide rich APIs and callable interfaces.

I’m currently finishing a project that uses Oracle’s Imaging and Process Management (OIPM) product. The customer’s version of OIPM targets Microsoft Visual Basic 6 .dlls for custom scripts, and Microsoft .NET 1.1 framework for web development. However, I wanted to target the 2.0 .NET framework for the process scripts, and the 3.5 SP1 framework for the web interface. The web interface solution in particular takes advantage of LINQ, XML data stores, implicitly typed variables, jQuery, and AJAX.

Fortunately, OIPM, while using a fairly old COM-based codebase itself, provides mechanisms that allow an engineer to retain the proven usefulness of OIPM image storage and workflow, but extend to .NET managed code for scripts and web development. The sum of the parts becomes a much more useful solution then if all development was restricted to a closed ECM system that did not provide APIs or was completely COM based.

If you wish to dig deeper, or need a solution, ImageSource  provides training, custom development, and field services for many of the popular ECM products.

Clint Lewis
Senior Systems Engineer
ImageSource, Inc.