Archive for category Tutorials

.Net web apps hosted in the Azure cloud

Update: 08 Oct 2012 I discovered that Azure will not allow usage caps, so I have discontinued my subscription in order to prevent excessive charges. I’ve left this post here for historical reasons. I may explore other hosting alternatives in the future

I’ve recently switched over two of my demo web apps I wrote some years ago into the Microsoft’s Azure cloud service, something that greatly simplifies deployment and reduces my web hosting costs.

The first is No longer active, see beginning of post My remote control demo application which was an exercise to show an example of the command pattern

More sophisticated is my blackjack game, No longer active, see beginning of post which in a previous post in I showed its design.

Given that I wrote these programs in 2009, I certainly would not implement them again in the same way, as I was using some old technologies that have since been superseded (web forms, Linq to Sql) and my code would this time around implement SOLID principles.

Having previously set up and deployed Ruby on Rails websites on the excellent Heroku platform, in comparison Azure requires much less initial set up. Azure being built into Visual Studios means the developer is shielded from the complexities of deployment.

Counting in Heroku’s favour is the deployment speed; simple Azure apps take at least seven minutes to deploy, compared to around 30 seconds for Heroku.

For example in Ruby On Rails once you have set up the rake file to deploy locally, you can make a few alterations to that file for production setting and then run it on the Heroku instance in exactly the same manner as deploying locally.
Azure invents a brand new deployment work flow for the local copy of the cloud, which feels alien.

However I’m somewhat comparing apples to oranges, but I thought I’d share my insights. As a platform I’ll now be using Azure over independent web hosting.

One minor gripe when migrating data from a non-azure database to an Azure database was being forced to create clustered indexes which were not necessary in the original database.

, ,

No Comments

Setting up Continuous Integration with Cruise Control.Net

I recently set up Cruise Control on Vista PC for development purposes and I thought it might be useful to document the process I followed.

If you don’t know what Continuous integration is then I recommend a that you read a brief overview of it by Cruise Control .Net developers

In my implementation there are 3 components to continuous integration system.

Source control (I am using VisualSVN)
Complier (MSBuild.exe, which is part of the .Net Framework)
Nunit, a unit test runner

The process involved is fairly straightforward. First the trunk of the source code is pulled from the repository to the working directory. MSbuild.exe compiles the source code, then the nUnit tests. Finally the tests are run against the complied code. The success or failure of of the tests is output as an xml file and is reported in web dashboard.

I have also installed CCtray, a program that runs in the systray showing the state of the last build. It allows builds to be run manually, as opposed to a on a timed interval . The CC web dashboard shows a wealth of information on the build state and if any Nunit tests have failed.

I achieved this by following instructions on The CCNET homepage which I’ve summarised below.

In my case the editing, building and testing of the code is done on my local machine along with hosting the source control. In a bigger environment your would host these services seperately for performance reasons, but in my scenario this is not an issue.

Having installed from the download page I installed setup.exe. The CCTray.exe will be installed once the server has been setup

Once CC net is installed the server must be started by running the CruiseControl.net icon on the desktop.

To test if the install was successfully, I pointed my browser to http://localhost/ccnet/ViewFarmReport.aspx

The first hiccup I encountered was a an IIS 7 error:
HTTP Error 500.23 – Internal Server Error
An ASP.NET setting has been detected that does not apply in Integrated managed pipeline mode.

Which was easily solved after a quick google, I found that the solution was to switch the application to a Classic mode application
pool

The server is controlled via it’s config file, which is found in C:\Program Files\CruiseControl.NET\server\ccnet.config. This file is at the heart if to the entire integration process, and contains the list of actions the server will complete on each build.

Any edits to ccnet.confg will restart the CCnet server.

To complete the first stage of a build, which is to checkout the latest version of the code, I added the source control block to ccnet.config. It which defines where code is within the repository and where it is checked out to. My example is for a SVN but Cruise Control.net supports many other source control systems.

<sourcecontrol type="svn">
  <trunkUrl>http://localhost:8080/svn/myproject/trunk</trunkUrl>
  <workingDirectory>c:\dev\ccnet</workingDirectory>
  <executable>c:\Program Files\VisualSVN Server\bin\svn.exe</executable>
  <username>username</username>
  <password>password</password>
</sourcecontrol>

The next step is to add to the config file instructions to build the code that has been checked out.

To do this I used the MSbuild.exe file found in C:\Windows\Microsoft.NET\Framework\v3.5. To save my aching fingers from typing too much, I added the above path to it to the system path.

Within the tags I inserted the block as below

 <msbuild>
          <executable>
            C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe
          </executable>
          <workingDirectory>c:\dev\ccnet\trunk</workingDirectory>
          <projectFile>project.sln</projectFile>
          <buildArgs>
              /noconsolelogger /p:Configuration=Debug /v:diag
           </buildArgs>
          <targets>Build</targets>
          <timeout>0</timeout>
          <logger>
           c:\Program Files\
       CruiseControl.NET\server ThoughtWorks.CruiseControl.MsBuild.dll
           </logger>
</msbuild>

This builds the code that has been checked out. Note that the workingDirectory values are the same.

I also added another block which complies the nUnit tests. In my case, the trunk directory that was checked out contains both the data classes and Nunit test classes so only one checkout was required.

Now that the code has been complied, the unit tests are to be run. I have added the path to the nunit exes to the system path. The Nunit-console.exe runs the tests and creates an xml file containing the status report of the tests run against the classes.

I added the exec block inside the tags

       <exec>
          <executable>nunit-console.exe</executable>
          <baseDirectory>
              C:\Program Files\NUnit 2.5.2\bin\net-2.0
          </baseDirectory>
          <buildArgs>
             c:\dev\ccnet\trunk\NunitTests\bin\Debug\NunitTests.dll 
           /xml:c:\testresults\testoutput.xml
           </buildArgs>
          <buildTimeoutSeconds>10</buildTimeoutSeconds>
          <successExitCodes>0,1,3,5</successExitCodes>
       </exec>

At this point in the build process the tests have been run, so I now wanted to display the results in the CC web dashboard. To do this, I merged the testoutput.xml file into the build status output. This block needs to be put inside the block

<merge>
        <files>
            <file> c:\testresults\testoutput.xml</file>
          </files>
</merge>

Finally I activated the xmllogger, by adding to the block the

Under this configuration it was possible for me to check code into the trunk of my project, and force a build that checked out the code and unit tests, and automatically ran the tests against it, outputing the results to a the CCNet web dashboard, via a single click.

This entire process can be run from the CCNet web dashboard, or more conveniently, the CCTray sys tray program. There is a moderate overhead in setting up continuous integration but the return on investment grows the longer the system is developed.

Where to go on from here?

My setup could be improved in a number of ways.

  1. Auto build on each commit by using a post commit hook on subversion
  2. Selenium testing for the web functional tests
  3. using FxCop to analyse the complied code to find improvements and include this in build reports

Some of these topics I will explore in future posts

, ,

1 Comment

Blackjack Web Application

This post will explain how how I created a blackjack simulator web application, in ASP.net.

Here is a demo site which you can try yourself

Look and feel is basic, but the demo remembers your user details and playing history upon registration.

Enjoy playing and feel free to post any feedback via the comments below.

My subversion repository hosts the project files containing the data classes, which build the BlackJackClasses.dll file . This file is referenced by Asp.Net Website Code which can be found here

To build the project from the source you will need Visual Studios 2008 IDE and access to a SQL Server database. As the user data is persisted to a SQL Server database you will need to run this SQL script on your database to create the required tables.

Compile the BlackJackClasses project first as this file handles game logic and database access.
You may wish to run Nunit unit and integration tests that I wrote for this project, which are in my subversion repository

You will need to add the dmbl file to this project to access the database via LINQ. Name this file DBBlackJack.dbml. Connect to your database and add the three new tables to the dbml file.

Once compiled, open the Web project, and add a reference to the dll the BlackJackClasses project has generated. You web project should now open.
The subversion repository can be found here

Data classes: http://www.michaelokarimia.com/examples/Exam/BlackjackClasses/BlackjackClasses/

Website: http://www.michaelokarimia.com/examples/Demos/BlackjackGame/trunk/

No Comments