AspPDF and AspJPEG on Windows Azure

I have recently began the process of migrating our .NET Application to a Windows Azure cloud service. Our application was heavily dependent on a number of COM Class components, these include AspPDF (for PDF production and manipulation) and AspJPEG (for image re-sizing). On a typical non-cloud IIS setup I would just register the DLLs (using regsvr32) on our production server and all would be fine!

In Azure the process is slightly different and I will answer my own question to assist those with similar challenges. This method can be used for any dll that needs to be registered on the server as part of the deployment process.

In order to register the AspPDF and AspJPEG components on a Windows Azure cloud service the DLL registration process must be incorporated into the deployment routine. When Azure unpacks the application it must fire a command to register the DLLs, this must be persisted on all VMs to ensure these dependencies work consistently in a cloud environment.

To achieve this we can instruct a command file to be executed on the target server. This task is defined in the ServiceDefinition.csdef file as follows:

<Startup>
  <Task commandLine="RegisterPersits.cmd" executionContext="elevated" taskType="simple" />
</Startup>

The elevated execution context ensures that this process must be carried out before the service goes live. The Azure Fabric Controller will look in the BIN folder for the .cmd file. You can create the .cmd in Notepad and then change the extension. Here is the contents of the .cmd file.

chcp 1252>NUL
regsvr32 /s .\library\asppdf64.dll
regsvr32 /s .\library\aspjpeg64.dll
exit /b 0

We are calling the regsvr32 tool with the parameter /s, this ensures that the response is silent, i.e. no pop-ups that will confuse the fabric controller. This is important as I wasted a great deal of time wondering why the deployment process was hanging on the initialisation phase...adding the /s parameters solved this problem!

In my case I placed the DLLs in a folder called library, but you can put them wherever you like providing they are correctly referenced in the .cmd file. Be sure also to set the following file properties for any DLL referenced in the startup command within Visual Studio:

Build Action: Content

Copy to Output Directory: Always

This additional process for registering DLLs adds an almost negligible amount of time to the deployment process. One other point specific to AspPDF, is the importance of using the correct DLL version. Persits issue a 32 bit and 64 bit dll, Azure VMs run in an 64 bit environment therefore it's important to register the asppdf64.dll in the above process, registering a 32 bit dll will throw a vague error within your application. Fortunately you do not need to purchase a separate licence for the 64 bit version of AspPDF.

I hope this will assists others facing similar problems migrating com class components such as AspPDF to Azure.