Apprenda 3.0 Brings Private PaaS to .NET Developers

I kicked off my tests by downloading Apprenda Express and launching its installer on a machine running the 64-bit edition of Windows 7. The installer checked for the Microsoft Web stack dependencies it required, and prompted me to provide any missing elements before continuing. I managed to pull down most of what I needed using Microsoft’s Web Platform Installer tool, including IIS 7, SQL Server Express Edition and an Express edition of Visual Studio.

I also downloaded and installed the software development kit for Apprenda, which came with solution templates for Visual Studio. For my first project, I used an Apprenda solution template to create a simple, database-backed “hello world” application, as laid out in the product’s developer tutorial. After writing and building my application, I ran the project through a deployment archive builder, which also shipped with the SDK.

The templates and archive builder got me started with the folder layout I needed for deploying to Apprenda, but as I soon learned, it was easy enough to adapt existing projects to run on the service without calling on the templates at all.

To get a feel for deploying existing applications on the service, I picked out a few popular open-source .NET applications from Microsoft’s Codeplex project foundry. I started with the aptly named BlogEngine.NET, which I configured to use a database back-end, rather than its default XML back-end, as described in the project’s documentation.

Next, I set the database connection string for the application to $#APPLICATIONCONNECTIONSTRING#$, a wild-card value that the Apprenda system swaps out for the correct value at deploy time.

Once so configured, packaging the code into an Apprenda deployment archive involved placing all the project files into a directory named “root,” which itself sat in an “interfaces” directory. The BlogEngine project archive included a SQL script (MSSQLSetup2.5.0.0.sql) for creating the tables it required. I renamed this file to ApplicationProvisioning_Script.sql, and placed it in a directory named “scripts,” within a “persistence” directory. I compressed the persistence and interfaces directories into a zip file, which was then ready for deployment.

I also tested with Umbraco CMS, which doesn't ship with SQL scripts for setting up the tables. Rather, the Umbraco installer creates its tables during initial set-up, and needs only a database onto which to install. For this case, I included a blank ApplicationProvisioning_Script.sql script in my deployment archive, which was sufficient to prompt Apprenda to create a blank database for use with the application.

Once running, the Umbraco CMS installer asks for credentials for the database associated with it to complete the installation process. I was able to access these credentials from a data management console in the Apprenda developer portal.

The third application I chose for testing was BugNET, which ended up requiring file and folder permission settings changes not accessible to an Apprenda developer. To get the application to work, I would either have to modify my Apprenda installation to make the requested permissions changes, or modify the application to no longer require them.

For each of my test applications, once I’d come up with my deployment archive, I visited the Web-based Apprenda developer console to give my application a name and description before uploading its deployment archive to the service. After uploading the archive, the Apprenda system would check to ensure that necessary elements, such as a valid database script, were in place, and if pieces were missing, the console would prompt me to provide them.

For instance, when I uploaded my Umbraco CMS deployment archive, the system notified me that the project’s use of “configSource” attributes to reference separate configuration files in the project’s web.config was unsupported. As suggested in the error message, I folded these configuration elements into the main configuration file.

To test my applications, I then would promote them from development to sandbox status, where I could launch them, carry out any additional configuration steps through the browser, and give the applications a run-through before promoting them from sandbox to production status.

With each redeployment, for instance, shifting from sandbox to production, the system wiped the databases associated with the applications.