Microsoft Azure Cloud Service is the paradigm for PaaS. As such, Microsoft Azure provides a high-level, application-hosting environment, which is modeled on services, roles, and instances. The specification of the roles in the service is referred to as the service model.
As we mentioned earlier, Microsoft Azure supports two types of roles: web roles and worker roles. We said that a web role is essentially a worker role plus IIS because they comply with the same running model where there is an entry point that interacts with the Azure environment and our custom code, regardless of whether it is a web app or batch process.
Microsoft Azure provides us with a comprehensive set of command-line tools to package our solutions to be deployed on the Cloud, as they should be wrapped into a single deployment unit that is called a package. A package is like a ZIP file with encryption. It contains every project component of the Cloud Service, so it is the self-containing artifact that goes onto the Azure platform to instruct it about setting up machines and code. This package, along with its configuration, represents the whole Cloud Service that Azure Fabric (the big brain of the Azure data center) can deploy wherever it wants. In terms of black-box reasoning, the input of a Cloud Service is package plus configuration, which we can produce using command-line tools or just using Visual Studio, starting from our classic .NET binaries.
The corresponding Visual Studio artifact for the package mentioned earlier is a project template called Microsoft Azure Cloud Service. It is a .ccproj project that wraps the .NET projects in order to produce the resulting compressed unit of deployment. Later in the chapter, we call this project wrapper to underline its purpose in the deployment process.
In fact, Visual Studio lets us automatically create the correct environment to deploy web and worker roles, without facing the complexity of the command-line tools, by installing the Microsoft Azure Tools for Visual Studio that, at the time of writing this book, are available in Version 2.3.
In this recipe, we'll learn how to choose the service model for a Cloud Service and create a project environment for it in Visual Studio.
For this recipe, we use Visual Studio 2013 with Microsoft Azure Tools installed. The goal of the recipe is to produce a sample package for the Cloud Service, from new or existing projects.
A Cloud Service is a composition of two scenarios: new or existing projects. We will split our recipe into two branches to support the two scenarios:
Open Visual Studio, and in the menu bar, navigate to File | New | Project.
From the installed templates, choose either the Visual Basic, Visual C#, or Visual F# node, and then, choose the cloud node. You will be prompted later about the actual programming languages you will use in your services.
Select Microsoft Azure Cloud Service.
In the Name text box, enter the name (
WAHelloWorld) of your wrapper project. Remember that this name is only used to represent our service container, not a real web project itself.By choosing this project template, VS opens the New Microsoft Azure Cloud Service windows.
If you want to create just the wrapper of your existing web/worker project, press OK and go ahead to Branch 2. You will add your binaries to the wrapper project later. If you want to create the wrapper and your web/worker projects from scratch, read the Branch 1 section.
Use the arrow keys to add/remove the projects that will represent your web/worker roles on the right-hand side. You can choose the following two projects:
The ASP.NET web role
The worker role
On the right-hand side pane, there will be the WebRole1 and WorkerRole1 entries. Customize the names of the two projects in
WebHelloWorldandWorkerHelloWorld, respectively, and go ahead.Customize the project templates you added, with the windows that Visual Studio displays later.
In the Solution Explorer, right-click on the solution and choose Add | Existing Project.
In the browsing window, locate your project and select the Visual Studio project file. Now, your existing project is linked to the new solution.
In the Solution Explorer, right-click on the
Rolesfolder in the wrapper project and navigate to Add | Web Role Project in solution or Worker Role Project in solution.In the Associate with Role Project window, choose the project(s) to add and confirm. Now, the project should appear under the
Rolesfolder of the wrapper.Tip
To be a compatible web role project, a project should be a valid web application, regardless of the engine it runs on. On the other hand, every class library could be potentially a worker role project. However, to let Visual Studio add your existing class library, you must edit the project file (
csprojin C#) as outlined at the end of the recipe.Right click on the wrapper project and choose Package.
When prompted with the Package Microsoft Azure Application window, leave the default settings and click on Package.
After few seconds of VS operations in the background, you will be prompted with a local filesystem folder with the output of the packaging process.
From steps 1 to 5, we created the Microsoft Azure Cloud Service project, the project wrapper that represents the unit of deployment for Azure. As mentioned earlier in the note, be sure to have installed the SDK and the latest VS Tools required to complete the recipe first.
In step 6, we chose between starting from scratch and using existing projects.
In steps 7 and 8, we added two projects, one web role and one worker role, from the choices of the wizard. We could also add another project template such as the following:
The WCF service web role
The cache worker role
The worker role with Service Bus Queue
In step 9, for each .NET project that we added in the step 7, Visual Studio launches the Project Template wizard. In the case of the WebHelloWorld one, VS opens the new ASP.NET project window that lets us choose the ASP.NET engine to reference in the project. In the case of WorkerHelloWorld, VS simply adds a class library to the solution.
From steps 10 to 13, we showed how to import an existing project into the solution and then into the wrapper project. Finally, in step 15, we built the package using the default settings. Actually, we would choose which service configuration to use to create the configuration file and which build configuration to use to build the assemblies.
In the note of step 13, we mentioned that every class library could be used in a wrapper project. In fact, the Azure runtime only needs a class library, and it searches in the Dynamic Link Library DLL for a class that inherits the RoleEntryPoint abstract class as follows:
public class WorkerRole:RoleEntryPoint
{
}This requirement is enforced only at runtime. At compile time, however, Visual Studio does not block us if we miss the RoleEntryPoint implementation.
However, users who try to add their class library to the wrapper could be shown a grayed option due to the inability of Visual Studio to distinguish a valid worker role from a generic class library.
So, we need to perform a tweak on the project file:
Locate the project file (
*.csproj, for example) of the class library to add it.Open it with Notepad.
Before the first
</PropertyGroup>closing tag, add the following line:<RoleType>Worker</RoleType>
Save the file, and in Visual Studio, reload the project.
Have a look at these MSDN links to get additional information:
Information on the latest Azure SDKs with release notes at http://msdn.microsoft.com/en-us/library/dn627519.aspx
How to upgrade an existing project with the latest version of Azure Tools at http://msdn.microsoft.com/en-us/library/jj131257.aspx