Windows Azure

Windows Azure, TDS, WCF, Silverlight and a few problems on the way Part IV – The Silverlight Project

paulschapman — Wed, 27 May 2009 03:08:59 GMT

Introduction

After a short sojourn with the Visual Studio 2010 Beta, I’m back with the next part. Pop quiz – can you run Visual Studio Team Foundation and Visual Studio Professional without Team Suite? Well some wit told a client you could not – so I spent some of the Bank Holiday proving otherwise – Another article there on setting it up, but in general it was incredibly easy for a server app! Anyway I digress back to the subject at hand – hosting a Silverlight Application in an Azure Application.

This was the part that gave me the most gotchas.

Adding a Silverlight Project to the Azure Solution.

Right click on the Solution and click on the ‘Add New Project’.

Select The ‘Silverlight Application’ – Give your Silverlight Application a name and then click on ‘OK’.

When you hit the ‘OK’ button you will be presented with a new window to create the Web Application that will host the Silverlight App. Well we already have a web app. It is the WebRole – for this reason we select the third option – ‘Link this Silverlight control into an existing Web Site’, if it has not already been selected.

Of the three options at the bottom ensure the first is selected, we will raid this page for some code. Deselect the Make it the start page and select the Enable Silverlight debugging option.

Now there is a known issue in the WCF Services SDK which may soon cause you at least a really annoying message; "this operation is not supported for a relative uri". While it is not fatal and you can ignore it – as a matter of good coding I tend to get rid of as many warning messages as possible. To fix it, open your machine.config (both x86 and x64 version), and delete the following section:

   <endpoint address="" binding="netTcpRelayBinding" contract="IMetadataExchange" name="sb" />

Linking your Silverlight Application to your Webservice

Now last time we created a Web Service and it is now time to link the Webservice to the Silverlight Application. Right click on the Silverlight application you have created last time, and select ‘Add Service Reference’

Click on the Discover button and it will search your solution for the Webservice. Give the Namespace a sensible name and click on OK.

Go to the ServiceReferences.ClientConfig file in the Silverlight Client that is created when you link a webservice. Look for the client tag;

<client>
    <endpoint address="http://localhost:51159/SimplicitaServices.svc"
        binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ISimplicitaServices"
        contract="SimplicitaServices.ISimplicitaServices" name="BasicHttpBinding_ISimplicitaServices" />
</client>

Change the port number to the same port number that your Azure project executes on. In my development environment this tends to be 81, for yours it might be different.

We nearly have set up the Silverlight application. One last task remains. Silverlight will not retrieve data from some sites, including some webservices unless it has been given permission. You do this by placing a clientaccesspolicy.xml file in the root of the web server. However for this site, which is being run in the virtual server of Visual Studio that in effect means the root of the site. So add a file with that name to your site and insert the following code;

<access-policy>
  <cross-domain-access>
    <policy>
      <allow-from http-request-headers="*">
        >
        <domain uri="*"/>
      </allow-from>
      <grant-to>
        <resource path="/" include-subpaths="true"/>
      </grant-to>
    </policy>
  </cross-domain-access>
</access-policy>

And there we have it. The Silverlight project is now ready for us to code whatever magic we may wish – which will have to wait till the next part – I’m just about to relax and watch the CSI episode set in a Science Fiction convention!

Windows Azure, TDS, WCF, Silverlight and a few problems on the way Part III – The Azure Project, and creating our Web service.

paulschapman — Fri, 15 May 2009 04:18:16 GMT

So far Parts I & II have not given us anything new – the code will work happily in an ASP.Net or a traditional client application. Now we get to a more interesting bit – creating our Azure Project.

Before we can create an Azure Project you will eventually have to go to the Azure Website – and download the Azure tools from here; http://www.microsoft.com/azure/windowsazurefordevelopers/default.aspx.

Once you have installed these on your development PC you can now create an Azure Project. You will notice that I have not suggested signing up even for a CTP account. The reason is that you can do your development locally – the Azure tools create a kind of mini-Azure on your development PC. This makes little difference now, but when the service is charged for it will make a difference.

To create an Azure Project, look under your chosen language (C# or VB.Net) and select the ‘Cloud Service’ leaf. Then choose the required template. Normally I have picked the ‘Web And Worker Cloud Service’ – this is because I invariably need both a web and worker role. Indeed this project, we will have both. Below

And that is it. We now have an Azure Project, that can be run locally to test it.

The Web service.

Now the Azure project will eventually have a Silverlight frontend and that creates a small problem. Silverlight is designed to be a lightweight download and for this reason it uses a subset of the full .Net runtime. This means that many of the functions that one might take for granted. To allow us the use of the full .Net runtime these are placed behind a WCF web service.

To create a web service you can host it within your Web role. So right-click on the Web role project and select ‘Add’, then ‘New item’

This will display the above window – select the WCF Service, and give it name then click on the ‘Add’ button.

This creates your Web Service, but we are not finished. Silverlight requires that a Web Service use basic binding. So change the binding of the service double click on the Web.config of the Web Role. Finding the <services> tag. Make sure the ‘binding’ attribute is changed to basicHttpBinding. The following code shows what the section should look like;

    <service behaviorConfiguration="NewsMashup_WebRole.NewsMashupServiceBehavior"
        name="NewsMashup_WebRole.NewsMashupService">
        <endpoint address="" binding="basicHttpBinding" contract="NewsMashup_WebRole.INewsMashupService">
            <identity>
                <dns value="localhost" />
            </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
    </service>
</services>

So this sets up our Azure project, and our web service.

Windows Azure, TDS, WCF, Silverlight and a few problems on the way Part II – Database access layer

paulschapman — Thu, 14 May 2009 03:23:21 GMT

Project Sourcecode: NewsMashup

In Part I of this series of articles I discussed the database that lies behind the application. Moving from the backend to the client side, it is now time to discuss the code which accesses the database and returns the data to application.

I have a standard class I use when accessing databases. The version I am using here is developed to connect to SQL Server but with some minor changes it would not be difficult to adapt to other databases, and I already have one for ODBC.

public Database(string Connection)
{
    connection = new SqlConnection(Connection);
    InitialiseCommand();
}

public Database(SqlConnection Connection)
{
    connection = Connection;
    InitialiseCommand();
}

public Database()
{
    connection = new SqlConnection();
    InitialiseCommand();

}

The above code shows the constructor for the data access layer. Essentially the constructor expects either a connection, connection string or nothing to be passed to the constructor. Each calls another function; InitialiseCommand() which sets up the command object and is below.

private void InitialiseCommand()
{
    try
    {
        if (dbCommand == null)
        {
            dbCommand             = new SqlCommand();
            dbCommand.CommandType = CommandType.StoredProcedure;  // default to Stored Prc

            if (connection != null)
            {
                dbCommand.Connection = connection;
            }
        }
    }
    catch (System.Exception ex)
    {
        throw ex;
    }
}

This initialises the Command object and sets the type to Stored Procedure, if the Connection object has been initialised the command objects connection is set to the connection object.

To execute stored procedures we need two. One to return a datatable, and one which does not

    public void Execute()
    {
        try
        {
            if (dbCommand.Connection.State != ConnectionState.Open) dbCommand.Connection.Open();
            dbCommand.ExecuteNonQuery();
        }
        catch (System.Exception ex)
        {
            throw ex;
        }
    }

    public DataTable Execute(string TableName)
    {
        SqlDataAdapter  da;
        DataSet         ds;
        DataTable       dt = new DataTable();

        try
        {
            da = new SqlDataAdapter(dbCommand);
            ds = new DataSet();
            da.Fill(ds,TableName);

            if (ds.Tables.Count > 0)
                dt = ds.Tables[0];
        }
        catch (System.Exception ex)
        {
            throw ex;
        }

        return dt;
    }
}

The first of these two methods is fairly simple. Essentially what it does is confirm the connection is open, if not the connection is opened. Then it executes the stored procedure. The whole lot is then wrapped in a try catch, which is thrown back to the calling application.

The second is more interesting. It uses a Data Adapter and Dataset to fill a table returned back to the calling programme.

These two methods cover all the various types of database action I might want to undertake.

The real magic here however is in the objects which inherit from this class.

public class NewsMashupDB : Database,IDisposable

The class inherits from the class defined in the code above. The constructor for the object is as follows;

public NewsMashupDB() 
    : base()
{
    
}

public NewsMashupDB(string ConnectionString) 
    : base(ConnectionString)
{

}

Thats it. There is two here – one initialises the connection string, the other does not. All the calling application need do is retrieve the connection string. Executing a stored procedure is equally simple. Here we have the stored procedure which executes the CreateStory stored procedure;

public void CreateStory(string Headline, string Description, string Url, string Supplier, long PubDateValue)
{
    SqlParameter paramHeadline      = new SqlParameter("Headline", SqlDbType.VarChar);
    SqlParameter paramDescription   = new SqlParameter("Description",SqlDbType.VarChar);
    SqlParameter paramUrl           = new SqlParameter("Url",SqlDbType.VarChar);
    SqlParameter paramSupplier      = new SqlParameter("Supplier", SqlDbType.VarChar);
    SqlParameter paramPubDate       = new SqlParameter("PubDateValue", SqlDbType.BigInt);

    CommandText = "NewsMashup.CreateStory";

    try
    {

        paramHeadline.Value = Headline;
        paramDescription.Value = Description;
        paramUrl.Value = Url;
        paramSupplier.Value = Supplier;
        paramPubDate.Value = PubDateValue;

        dbCommand.Parameters.Clear();

        dbCommand.Parameters.Add(paramHeadline);
        dbCommand.Parameters.Add(paramDescription);
        dbCommand.Parameters.Add(paramUrl);
        dbCommand.Parameters.Add(paramSupplier);
        dbCommand.Parameters.Add(paramPubDate);

        Execute();
    }
    catch (System.Exception ex)
    {
        throw ex;
    }
}

Except for the code setting up the parameters required the execution of the stored procedure takes two lines; one to initialise the command text, the other to execute the stored procedure.

A stored procedure which returns data is equally simple.

public DataTable RetrieveNewsFeeds()
{
    DataTable dt = new DataTable();

    try
    {
        CommandText = "NewsMashup.RetrieveNewsFeeds";

        dt = Execute("NewsFeeds");

    }
    catch (System.Exception ex)
    {
        throw ex;
    }

    return dt;
}

It is clearer here than in the other method, again only two lines of code; one to initialise the CommandText the other to execute the stored procedure. This version of the Execute returns the datatable containing the results of the stored procedure’s execution.

This shows examples of the code. The rest should be in the attached zip file

Getting WCF to work with Azure

paulschapman — Thu, 08 Jan 2009 05:04:11 GMT

Silverlight makes creating compelling Rich Internet Applications fairly easy. That said the cut down version of .Net means some things that you would do within an application have to be relegated to Web Services which can benefit from the full .Net library. One of these is of course Azure, after all that is the whole point - an online store of Business Logic and data.

The application I'm working on uses Silverlight on the front end, and Azure will provide the bulk of the backend. There are reasons for this; my budget for the site is not that large, adopting Azure means first off that it will be free during development, but almost as important - hosting costs will be related to the success of the site.

Thing is dealing with pre-beta software has meant an increase in grey hairs and those that are left are getting fewer. One of the parts that needs looking at is in WCF. If you run the Azure Labs the WCF lab does not work. This is because the Development Fabric is not hosting the service correctly, and WCF metadata is not being returned correctly.

Thanks must go to David Burela and his House-o-blog. In it he describes a way to get WCF working despite the problems with the Development Fabric. So what I thought I would do is write a version of the Azure Services Training Kits Exercise 3: Hosting a WCF Service

So the following is Exercise 3, but with the changes made to ensure it works

1. Open the project you created in Exercise 2 or open the begin.sln solution file located in C:\AzureServicesKit\Labs\BuildingWindowsAzureServices\Ex03-HostingWCFService\begin\.

Note:

If you closed Visual Studio, be sure to open it elevated as Administrator, from Start | All Programs | Microsoft Visual Studio 2008 right-click Microsoft Visual Studio 2008 and choose Run as Administrator.

2. Add the WCF service file. To do this, right-click the RDCompute_WebRole node in Solution Explorer, point to Add and select New Item. In the Add New Item dialog, select the WCF Service template, change the Name to MessageLogger.svc, and then click Add.

Note:

The template adds an IMessageLogger interface, which defines the service contract and a MessageLogger class that implements the contract.

3. Update the contract interface to define a method to send messages to the service. Open the IMessageLogger.cs file in the text editor. This file contains the generated IMessageLogger interface, which includes a single method named DoWork. Delete this method, and insert a LogMessage method to replace it (shown highlighted in bold text below.)

[ServiceContract]
public interface IMessageLogger
{
[OperationContract]
void LogMessage(string message);
}

4. Implement the contract interface in the MessageLogger service. Open the MessageLogger.svc.cs file in the text editor. This file contains the service implementation and includes a skeleton DoWork method. Again, delete this method and insert the following code that implements the LogMessage method in its place.

public void LogMessage(string message)
{
MessageHelper.SaveMessage(message);
}

5. Change the binding of the IMessageLogger endpoint to use a basicHttpBinding. Open the Web.config file in the text editor and locate the RDCompute_WebRole.MessageLogger service configuration in the services section inside system.serviceModel. This should be towards the end of the file. Change the binding attribute of the single endpoint contained in this section from wsHttpBinding to basicHttpBinding. The endpoint configuration after the change should be as follows:

<endpoint address="" binding="basicHttpBinding" contract="RDCompute_WebRole.IMessageLogger">
  <identity>
    <dns value="localhost" />
  </identity>
</endpoint>

 
6. Right click on the ASP.Net project (AzureWCFDemo_WebRole) and set it as the startup project
 
7. Right click on the MessageLogger.svc file and select View in Browser
 
8. When IE starts copy the address displayed in the Address Bar to the clipboard
 
9. Start a new instance of Visual Studio
 
10. Create a console client project by select File, New Project
 
 

 
11. Add a reference to the message logging service. In Solution Explorer, right-click the MessageGenerator project node, and select Add Service Reference. 
Paste the address you copied from the IE instance into the Add Service Reference dialog and click Discover. Change the Namespace to RDService and click OK
 
12. Add the following code to the main function
 
using (RDService.MessageLoggerClient client = new RDService.MessageLoggerClient())
  {
    Console.WriteLine("Enter your messages ('quit' to exit)");
    while (true)
    {
      try
      {
        string message = Console.ReadLine();
        if (message.Equals("quit", StringComparison.CurrentCultureIgnoreCase))
          break;
        client.LogMessage(message);
      }
      catch (Exception ex)
      {
           Console.WriteLine(ex.Message);
      }
    }
  }

 
13. Return to the instance of Visual Studio running the ASP.Net application and stop debugging the ASP.Net Application
 
13. Right click the Azure project and set as the Start-up project, then start debugging. The Dev Fabric should start running and hosting the WCF service. 
When IE starts note the port number. More than likely this will be 81.
 
14. Finally, go back to our client project. Open the app.config file and change the endpoint address so that is the port number found in the previous step.
 
15. Now run the client project. It should be able to call the WCF Service hosted within the Development Fabric
 
If everything worked you should have completed Exercise 3. Hopefully a fix to the problem will be forthcoming. Excercise 4 should be fun, since in this instance 
we will be calling the Web Service from within Azure (rather than a standard Windows Application) and so this technique may need adapting.