The Thinkwise Platform supports various types of report generation solutions. The choice for a certain type of reporting has functional implications. For instance, not all reporting solutions support the usage of sub-reports. Other reporting solutions may offer more features regarding the use of SVG images or HTML markup.

There are also non-functional aspects to consider. License costs is often noted. Another important aspect is the portability of the reports. Not every type of report can run on both Windows and Linux environments.

Quite some research has gone into the portability of the usage of Crystal Reports lately. We’d like to share some of our findings in this blog.

Runtime installation

Administrators who have deployed applications using Crystal Reports know that it requires the installation of the Crystal Reports runtime. Either on the desktop clients when the Windows GUI is used or on the web server when the reports are generated by Indicium, the Application Tier, or the Web GUI.

As breaking changes in versions may happen overnight, a download location for the specific compatible MSI to install the Crystal Reports runtime can be found in our docs.

PaaS offerings

When web server applications are not installed on-premises but in the cloud, we may run into some problems regarding the portability of these reports. Specifically, when we want to run the web server application as a PaaS solution.

A PaaS offering, such as Azure Web Apps, aims to virtualize the entire underlying environment. This includes virtualization of the hardware, operating system but also the frameworks and libraries used to run the application. The only thing you add on top is your own packaged application.

This allows the cloud provider to offer efficient balancing and scaling solutions and spin up new environments very quickly, as only the packaged application needs to be distributed.

Because of this, installation of the Crystal Reports runtime in a PaaS solution is not possible. It cannot be included in the package as a library but needs installation of the runtime.

This is not limited to just the Crystal Reports runtime but also affects other libraries that cannot be packaged with the application but require installation, such as specific database drivers or interop-integrations with Microsoft Office.

Taking a step back

Ok, so we cannot use Azure Web Apps to host our web application that uses Crystal Reports. Can we still deploy our application in Azure?

A virtual machine is often suggested as the solution. We will lose quite some flexibility in comparison to PaaS offerings. Maybe it is time to reconsider using Crystal Reports, yielding some functional requirements in the process?

Let’s not be too hasty. We are jumping straight from PaaS, virtualization of everything but the application package, to a VM, virtualization of the hardware. We should not skip over an important intermediate solution, virtualization of the operating system.

We can use a container to deploy our web application. A container provides most of the same benefits that a PaaS offering has, while we still have enough control of the environment to install a runtime.

Docker container example

Here is a quick example on how to create a container image containing the Web GUI with an installed Crystal Reports runtime. Since we are using a Web GUI, we’ll need a Windows container that is based on IIS.

The following folder structure is used:

dockerfile
Resources
  oledlg.dll
  CR13SP25MSI64_0-10010309.MSI
WebGUI
  App_GlobalResources
  App_LocalResources
  bin
  settings.ini
  n...]

The Web GUI has been downloaded from TCP and the settings file has been configured in advance for the environment I want to use.

The MSI requires a dll file that we’ll also have to copy into the image. The core Windows Server image is very small, stripped of most UI aspects but the absence of this dll file causes the installation to fail. The dll can be found at the following location: C:\Windows\SysWOW64\oledlg.dll

Depending on the font usage of your reports, you may also have to add some fonts to the container as most are omitted from the base Windows Server image for the same reason.

The dockerfile will look something like this:

#Base Windows server with IIS
FROM mcr.microsoft.com/windows/servercore/iis

#Install features we need for the Web GUI
RUN powershell.exe Install-WindowsFeature NET-Framework-45-ASPNET
RUN powershell.exe Install-WindowsFeature Web-Asp-Net45

#Hack in oledlg dll so that Crystal Runtime will install
COPY ./Resources/oledlg.dll /windows/syswow64/oledlg.dll

#Copy in Crystal MSI 64 bit and install.
COPY Resources/CR13SP25MSI64_0-10010309.msi .
RUN powershell.exe -Command Start-Process CR13SP25MSI64_0-10010309.msi -ArgumentList '/quiet' -Wait

#Add website files
COPY ./WebGUI /inetpub/wwwroot/WebGUI

#Create the website, application pool etc.
RUN powershell.exe Remove-Website -Name 'Default Web Site'
RUN powershell.exe New-Website -Name 'web-cr' -Port 3000 -PhysicalPath 'c:\inetpub\wwwroot\WebGUI' -ApplicationPool '.NET v4.5'

EXPOSE 3000

The container image resulting from the build can be published (for instance in a private Azure Container Registry) and deployed in Azure. The cloud provider can take care of OS patching, capacity provisioning and load balancing.

While this example uses a Web GUI, a similar approach can be used for Indicium, the Application Tier.

Closing

In an ideal world, we’d be able to package all dependencies directly with the web applications and achieve maximal portability. But the reality is different.

Containers are a fantastic solution that allow the installation of dependencies while retaining more flexibility and scalability compared to virtual machines.

As mentioned in an earlier blog, we are currently working on setting up a container registry where we will publish container images for Thinkwise runtime components to easily install (and update!) containerized application environments. We’ll keep you posted here on the community!