Side by side versioning of Internet Explorer ActiveX Addons (with the same filename)

I first encountered this issue today, where the client had packaged two versions of the SQL Server Reporting Services Client Printing ActiveX.  There are separate version for SQL Server 2005 and 2008 Reporting Services.  However, both of these ActiveX controls have identical filenames (rsclientprint.dll).

This was a manually created package, and the following guide suggests if you don't allow standard users to install via ActiveX controls via GPO, then to package the ActiveX using the following method.

So how do we know if these ActiveX controls are meant to run side-by-side or not?

(The following excerpt is from: http://www.kodyaz.com/articles/client-side-printing-silent-deployment-of-rsclientPrint.aspx)

---

Reporting Services Client-Side Printing and Silent Deployment of RSClientPrint.cab ActiveX file.

RSClientPrint.cab is a Microsoft ActiveX control that provides client side printing for Microsoft SQL Server Reporting Services reports.
The ActiveX control displays a custom print dialog box that supports common features with other print dialog boxes. The client-side print dialog box includes a printer list for selection, print preview option, page margin settings, orientation, etc.
Downloading and installing the ActiveX control RSClientPrint.cab requires administrator permissions on the client machine.
If a user runs a SQL Server Reporting Services report and if the toolbar is displayed, the user can click on the print buttons seen on the right side of the toolbar.


If the print command is being run for the report server by that user's client machine then the client request the RSClientPrint.cab download from the related Report Server. While downloading the ActiveX software the browser will promt the user whether the software will be installed or not considering the security issues. Again, it is necessary to note that administration permissions are required for downloading and installing the rsclientprint ActiveX. For RSClientPrint install, RSClientPrint.cab download is the first step in installing the ActiveX on IE browser.


After the installation of the RSClientPrint is successfully done, the Print dialog box is displayed as shown below. You will realize that the Print options is very similar to standart Print dialog boxes that run on Windows systems including preview, number of copies, print range, printer selecting from available printers, etc.


Print Preview option for the Reporting Services report.

rsclientprint.cab and rsclientprint install

In most companies the Information Technology policies do not grant the admin privileges to the end users. So the end users running on the client computers can not download and install the ActiveX print client file RSClientPrint.cab.
So it is a need for the IT departments to distribute this client side printing ActiveX control in order to support their clients to work with SQL Server Reporting Services (SSRS) without a problem.
You can find the file rsclientprint.cab on the Report Server bin folder. The Reporting Services Report Server folder can be on
C:\Program Files\Microsoft SQL Server\MSSQL\Reporting Services\ReportServer\bin folder for SQL Server 2000 Reporting Services and
C:\Program Files\Microsoft SQL Server\MSSQL.4\Reporting Services\ReportServer\bin folder for SQL Server 2005 Reporting Services.
Actually for SQL Server 2005, the installation folder may vary due to the installed components of the SQL Server 2005. You can also find the ReportServer bin folder by openning the IIS Manager and then exploring the ReportServer (if installed with default settings) virtual directory.


If you extract the contents of the RSClientPrint.cab file you will see that the .cab file consists of the following files.
gdiplus.dll
RSClientPrint.dll
RSClientPrint.inf
RSClientPrint_1028.rll
RSClientPrint_1031.rll
RSClientPrint_1033.rll
RSClientPrint_1036.rll
RSClientPrint_1040.rll
RSClientPrint_1041.rll
RSClientPrint_1042.rll
RSClientPrint_1043.rll
RSClientPrint_1046.rll
RSClientPrint_1053.rll
RSClientPrint_2052.rll
RSClientPrint_3082.rll

For a silent deployment of RSClientPrint.cab, you only need to distribute RSClientPrint.dll file and the .rll files.
If you copy the files listed below under the folder C:\WINNT\system32 for client computers.
RSClientPrint.dll
RSClientPrint_1028.rll
RSClientPrint_1031.rll
RSClientPrint_1033.rll
RSClientPrint_1036.rll
RSClientPrint_1040.rll
RSClientPrint_1041.rll
RSClientPrint_1042.rll
RSClientPrint_1043.rll
RSClientPrint_1046.rll
RSClientPrint_1053.rll
RSClientPrint_2052.rll
RSClientPrint_3082.rll
Register the RSClientPrint.dll dll file by running the regsvr32.exe command on the command prompt shown as below.
c:\regsvr32.exe /s
c:\winnt\system32 \rsclientprint.dll

So, if a script or an MSI file that copies the listed files above and registers the rsclientprint.dll will be enough to deploy the Reporting Services Client Side Printing functionality.

SQL Server 2008 Reporting Services on Windows 7 RSClientPrint.cab ActiveX file

Windows 7 has been released and SQL administrators and BI developers can start working on SQL Server 2008 on Windows 7 with its one of Business Intelligence (BI) components Reporting Services.
What is changed for SQL2008 SSRS is that the default bin folder of the ReportServer 2008 where new RSClientPrint-x86.cab, RSClientPrint-x64.cab or RSClientPrint-ia64.cab ActiveX file download can be found at :
C:\Program Files\Microsoft SQL Server\MSRS10.MSSQLSERVER\Reporting Services\ReportServer\bin
If you are working on Windows 7 with MS SQL Server 2008, you can review the contents of the new RSClientPrint.cab file downloads.

---

Firstly, it's worth noting, that installing an IE ActiveX into the SystemFolder is a very bad idea, as you would need to mark the component as Permanent, as per Windows Installer Best Practice.  If you don't mark the component as Permanent, you'll get an ICE09 error.  Therefore, this should be shifted into ProgramFilesFolder. 

Ignoring the obvious issue that the guide tells you to install to C:\WINNT path, it is important to note that the two different ActiveX controls have identical filenames. But if you look at the COM registration information of each of the ActiveX controls using a utility like RegSpy, then you'll see that the Class ID GUIDs are actually different.  They do not use any version independent ProgIDs, and you would therefore encounter a problem if you were to author a package which installs both of these ActiveX controls to the same path.  Therefore, are these two really meant to run side by side?  Or is the 2008 ActiveX control a replacement for the 2005 ActiveX (thus offering backwards compatibilty).

To find out, you need to understand what the native behaviour is, and how Windows/Internet Explorer handles this natively when this situation is encountered.

If you have administrator privileges, you'll need to go to a site that uses SQL Server 2005 Reporting Services, select a report, and click on a printer icon, which will prompt you to download and install the ActiveX.  Internet Explorer downloads and registers ActiveX controls at C:\Windows\Downloaded Program Files\.  See screenshot below:

So here comes the interesting part.  When I visit a site which requires the SQL Server 2008 Reporting Services Client Printing ActiveX, it actually doesn't uninstall or touch the old one at all.  They actually install side by side, but how is this possible?

Well, if you look at the installation path of RSClientPrint 2008 ActiveX, you'll see that Internet Explorer has intelligently put it in a subfolder called CONFLICT.1.

Therefore, from this we can conclude that the two packages can co-exist, and you should be author each package to install to a unique path.

So the key points are:
 - Don't register IE ActiveX addons into the SystemFolder (otherwise the IE addon will never be uninstalled)
 - Don't assume the newer ActiveX controls offer backwards compatibility just because the filenames are the same.  Look at the COM registration information for leads.
 - If you already have two manually created packages that conflict, then look at how the vendor's default installation behaviour manages the conflict.