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
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
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 (MSSQLSetup220.127.116.11.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
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
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
With each redeployment, for
instance, shifting from sandbox to production, the system wiped the databases
associated with the applications.