Category Archives: How To

Two Roles and a Queue – Creating an Azure Service with Web and Worker Roles Communicating through a Queue

Two Roles and a Queue Lab from Boston Azure Firestarter

At the Firestarter event on May 8, 2010, I spoke about Roles and Queues and worked through a coding lab on same. The final code is available in a zip file. The Boston Azure Firestarter – Bill Wilder – Roles and Queues deck can be downloaded – though since there were so many questions we didn’t get to covering a number many of the slides! – this was a hot topic!

The remainder of this post contains the narrative for the LAB we did as a group at the Firestarter. It probably will not stand alone super well, but may be of interest to some folks, so I’ve posted it.

The following procedure assumes Microsoft Visual Web Developer 2010 Express on Windows 7. The same general steps apply to Visual Studio 2008, Visual Studio 2010, and Web Developer 2008 Express versions, though details will vary.

0. Open Microsoft Visual Web Developer 2010 Express and select File | New Project

1. Select Windows Azure Service and click Okay:

image

If you have trouble finding the Windows Azure Service template, you can type “Azure” into the search box in the top-right to narrow the options. Also, if you don’t have the Windows Azure SDK installed, you will need to install that before proceeding – but there will be a link provided by Visual Web Developer 2010 Express that will direct you to the right page. Install it if you need to and try again up to this point.

2. You will see a special dialog box for New Cloud Service Project from which you will add both a Web Role

image

and a Worker Role

image

Verify that both WebRole1 and WorkerRole1 are in the list on the right side, then click OK.

3. Before you begin making code changes, you can run your new application. You can run it in the debugger by pressing the F5 key.

You will probably get the following error message:

image

The error message is telling you that you need to close Visual Web Developer 2010 Express and restart it with elevated privileges.

4. To start any Windows program with elevated privileges , right-click on the application then choose Run as administrator from the pop-up menu:

image

Before it obeys your request to run as administrator, Windows 7 will double-check by popping up a security dialog.

Now you can reload your project and try running it again. The app should run and you should see a blank web browser page.

5. Once you’ve proven your application runs, it is time to make some changes.

Make the code changes indicated for the Two Roles and A Queue Lab in CODING STEP 1.

Note: the “coding step 1” and future coding steps were handouts (paper!) at the Boston Azure Firestarter on Sat May 8, 2010. In lieue of reproducing them here, I will post the final solution.

This lab will establish some WebRole basics.

6. When done applying CODING STEP 1, run the application again.

7. After demonstrating your application runs, Deploy it to Azure.

This is a simple application so it helps us get through the initial deployment with minimal challenges.

8. Apply CODING STEP 2 – Add Queue (in local dev fabric storage)

9. CODING STEP 3 – Add “DumpQueue” method and “FirestarterWebRoleHelpers.cs”

image

You will get the following dialog box – type “code file” into the search area on the top-right, select Visual C# Code File, and type in the filename “FirestarterWebRoleHelpers.cs” as shown and click Add:

image

The new file “FirestarterWebRoleHelpers.cs” will open in the editor. It should be empty to begin with. Cut and Paste in the contents from http://bostonazure.org/files/FirestarterWebRoleHelpers.cs.txt.

Why? The contents of this file has little to do with Windows Azure, so we don’t want to focus on it. But we want to use some utility routines from it so that we can focus on Azure concepts.

10. CODING STEP 4 – Adding Cloud-based Queue

First we need to configure the cloud.

Go to http://windows.azure.com and log in. You may wish to consult instructions on redeeming a token at http://blog.codingoutloud.com/2010/05/06/redeeming-an-azure-token/ or http://bit.ly/dgCuMn

image

Your storage account has a subdomain, as circled above. This – and the Access Key – need to be added to your Web Role and Worker Role so that they can access (and share the same queue within) cloud-hosted storage.

Right-click in Visual Studio on the WebRole1, select Properties, and select the Settings tab on the left. It will appear something like this:

image

Now click on Add Setting and give the new item the name “DataConnectionString”, the Type “Connection String”, and click on the “…”

image

This will bring up the Storage Connection String editor – fill in the fields – where your “Account name” is the same as the subdomain shown on the Storage Service (see above – in that screen shot it is “bostonazurequeue”) and the Key can be either Primary or Secondary Access Key (from same area in the Azure Portal):

image

You are NOT DONE in the screen yet. Also add a Setting named “StatusUpdateQueueName”– of Type “String” – with Value “updatemessagequeue1” as follows:

image

Click OK.

11. Now REPEAT BOTH STEPS for WorkerRole1.

Yes, add both Settings also to WorkerRole1 – they both will end up with the same settings. You can “cheat” with cut and paste in the .cscfg and .csdef files.

12. Enable Cloud-hosted Queue from Web Role

Now you are ready go on to make the code changes to use this new configuration item.

Apply CODING STEP 4: Enabling the Cloud-hosted Queue from the Web Role

Now run your application using cloud storage for the queue:

image

Note that you can also examine the contents of the queue online by visiting http://myAzureStorage.com and providing the same credentials you used when setting up the DataConnectionString above for both the Web and Worker roles.

13. Enable Cloud-hosted Queue from Worker Role

Now you are ALMOST ready go on to make the code changes to use this new configuration item.

Before applying the coding, we need to add a project reference (otherwise you won’t be able to Resolve use of networking classes used in the FirestarterWorkerRoleHelpers.). In Visual Studio on the right side, under the Solution Explorer, right-click on the References element underneath WorkerRole1 and select Add Reference, then from the .NET tab, select System.Web and click okay:

image

Also, similar to step 9 above, add a new Code File called “FirestarterWorkerRoleHelpers.cs” to hold some additional needed (but not core to Azure) code.

The new file “FirestarterWorkerRoleHelpers.cs” will open in the editor. It should be empty to begin with. Cut and Paste in the contents from http://bostonazure.org/files/FirestarterWorkerRoleHelper.cs.txt.

Now you can apply Apply CODING STEP 5: Enabling the Cloud-hosted Queue from the Worker Role.

14. Deploying to Staging Area in Cloud to Staging

15. Cutover from Staging to Production

16. Add in secret Twitter posting code from your Worker Role…

Yes, this can be done by including a hash character (#) as part of the message you type into your web application.

Redeeming an Azure Token

At some select events (like Boston Azure Firestarter, Boston Azure User Group hands-on meeting, or even Protein Folding with Azure @home), Microsoft sometimes provides tokens for participants who wish to try out Windows Azure for real – by deploying real bits into the cloud – deploying multiple instances of Web Roles and Worker Roles, using Queue for scaling, storing data and blobs in Azure Storage and exercising SQL Azure… Some of the tokens are good for up to 4 weeks – which is awesomely convenient for really kicking the tires on Azure if you are a developer. Which I am… Here is a little guidance on getting your account set up once you have a token in hand.

Note that you will be interacting with the Windows Azure Developer Portal (or Dev Portal for short) to redeem your token and establish your temporary account. The Dev Portal is useful to learn about and get to know.

1. First visit http://windows.azure.com and log in with the provided credentials. Use the provided email address for your Windows Live ID.

(NOTE: If any of the images in this post are too small to read, click on them to see a larger version.)

image

2. You will see a screen like the following. Note the row with the light blue background; this background color only appears when your mouse is hovering there. Click on the Project Name that matches your token account name.

image

(Notice that the account owner is “waaccts@microsoft.com” – this is because you are using a Token. Azure supports having an overall account that pays the bills, then sub-accounts for developers. This is an example.)

3.  Now you are in! You can proceed to review some of the help resources lists, or click around on any of the tabs to the left. But to create a new application that you can host on the Azure cloud, you can click on the “New Service” link next to the green “+” sign.

image

4. After you choose “New Service” you will see the following. Note the two main options in the middle for Storage Account and Hosted Services.

image 

Select Hosted Services to begin. Be sure to click on the words “Hosted Services” as opposed to the “Learn More” link, as they are different.

5. The next page will ask you for a name – this name will only be used to help you identify this service from a list in the developer portal, so don’t spend too much time coming up with the perfect name. You don’t need to provide anything for the Description.

image

After providing a name, click Next.

6.  Now you are faced with a form where the choices you make actually do matter.  Here’s what’ you’ll need to do:

image

Type in a “Public Service Name” – this will be the Internet-visible sub-domain from which your deployed application will be visible. For example, if you choose “foo” then your Azure Service will live at http://foo.cloudapp.net after you publish it.

After you settle on a Public Service Name (using Check Availability button as need), you also need to select a Region. Pick the “anywhere” region in your continent (or closest to your continent) such as Anywhere US and click Create.

Here’s what mine looked like before I clicked Create:

image

Now your Azure Service has been created.

7. You will see a screen inviting you to Deploy a Hosted Service Package. We won’t do that now (though you could if you had an application ready). Instead, we will create an Azure Storage Account. From here:

image

Click on the “New Service” link which is near the top-left – below the large Windows Azure logo – and you will see the same screen you saw in step 4:

 image

This time select Storage Account and you will see the following:

image

Give it a name, as I did in screenshot, and click Next.

8. As in step 5, this is also an important choice, though not visible to humans visiting your site. You will need to know this address to program against it. Of course you can look it up in the Dev Portal at any time, but why not choose a logical name. Fill in the fields similar to step 5 – be sure to choose the same Region you chose with step 5 – and click Create.

image

9. You are now ready to build and deploy Azure applications that use Web Roles, Worker Roles, and various kinds of storage.

You will need the keys shows to programmatically access your storage.

image

You can always come back and look up the values of these keys, of course. Also, if a key is compromised, you can regenerate it easily, invalidating the prior one. There are two separate keys that can be used/invalidated independently. These keys are specific to this Storage Service you created; you can create more Storage Services with different keys and even use multiple of them together.

Three ways to tell if a .NET Assembly (DLL) has Strong Name

Three ways to tell if a .NET Assembly is Strongly Named (or has Strong Name)

Here are several convenient ways to tell whether a .NET assembly is strongly named(English language note: I assume the form “strongly named” is preferred over “strong named” since that’s the form used in the output of the sn.exe tool shown immediately below.)

Towards the end, this post discusses use of Strong Names with Silverlight.

Then in the final section of this post the often confusing – though very important – differences between Strongly Named assemblies and Digitally Signed assemblies are clarified.

But first, here are three approaches for telling whether a .NET Assembly is Strongly Named...

Approach #1: Testing for Strong Name on Command Line or in a Script

You tell whether an Assembly/DLL has been successfully strong-named using the Strong Name Tool (sn.exe) (which can be found somewhere like here: C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\sn.exe) by running the following at the command line:

sn -vf System.Data.dll

Here are the results when running against a strongly named assembly, then one that is not strongly named.

C:\> sn -v C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\System.Data.dll
Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30128.1
Copyright (c) Microsoft Corporation.  All rights reserved.
Assembly 'C:\...\System.Data.dll' is valid
C:\> sn -v C:\WINDOWS\ismif32.dll
Microsoft (R) .NET Framework Strong Name Utility  Version 4.0.30128.1
Copyright (c) Microsoft Corporation.  All rights reserved.
C:\WINDOWS\ismif32.dll does not represent a strongly named assembly

Since the return value from sn.exe is 0 (zero) when the strong name is in place, and 1 (one) if not correctly strong named, you can test for this in a script by examining ERRORLEVEL, as in the following (put it into a text file called “sn-test.bat” for example and run as “sn-test foo.dll”):

@ echo off
if "%1"=="" goto END 
sn -q -vf %1 > NUL 
if ERRORLEVEL 1 goto NOT_STRONG
:STRONG
echo Has strong name: %1
goto END
:NOT_STRONG
echo Not strong named: %1
goto END
:END

Note that this will tell you whether it has SOME strong name, but does not tell you which one. So this technique is not appropriate for all uses, but might help in, say, an automated script that checks your about-to-be-released assemblies to make sure you remembered to add the strong names to them. (See note below – “Strong Names not for Security”.)

If you need finer-grain control and wish to write low-level code to ascertain the strong-naming status of an assembly, you can do that too.

Approach #2: Viewing Strong Name Details with IL DASM

Visual Studio ships with a handy utility – the Microsoft Intermediate Language Disassembler (ILDASM.EXE (tutorial)) – which can be used for disassembling .NET binaries to peruse the contents, perhaps for viewing the method signatures or viewing the .NET Assembly Manifest. It is helpful to load an assembly using IL DASM and examine the manifest to see whether there is a strong name key available. Your first step is to load the desired Assembly using the ildasm.exe utility. On my Windows 7 machine, IL DASM is found at

C:\Program Files\Microsoft SDKs\Windows\v7.0A\bin\ildasm.exe

and you can load up the System.Drawing.dll .NET Assembly as in the following example:

C:\> ildasm C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll

Once loaded, you will see a screen like the one below.

Note the MANIFEST section highlighted. Double-click on MANIFEST which load the following screen of manifest-specific data:

Find the section for the Assembly you’ve loaded – in this case, System.Drawing and following the section (which is marked with the “.assembly System.Drawing” directive highlighted above, and the content begins with the opening brace (“{“) shown above, and ends with its matching brace later in the manifest, and shown below.

The highlighted part of the manifest is the public key for this assembly. This public key can also be seen using the sn.exe tool, as follows:

C:\> sn -Tp C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Drawing.dll echo Not strong named: %1
Microsoft (R) .NET Framework Strong Name Utility  Version 3.5.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved.
Public key is 002400000480000094000000060200000024000052534131000400000100010007d1fa57c4aed9 f0a32e84aa0faefd0de9e8fd6aec8f87fb03766c834c99921eb23be79ad9d5dcc1dd9ad2361321 02900b723cf980957fc4e177108fc607774f29e8320e92ea05ece4e821c0a5efe8f1645c4c0c93 c1ab99285d622caa652c1dfad63d745d6f2de5f17e5eaf0fc4963d261c8a12436518206dc09334 4d5ad293
Public key token is b03f5f7f11d50a3a

Note that the Public key in the output from sn.exe matches the highlighted public key in the image immediately above it (of course you should ignore the spaces between pairs of digits in the screen shot).

If an assembly is not strongly named, the Public key will be missing from the manifest and will not be displayed by sn -Tp command.

Since IL DASM comes with both Visual Studio and with the .NET SDK, it is already on the desktop for most .NET Developers, and is therefore sometimes the handiest tool. The third option, .NET Reflector, is a third-party tool, though one adopted by many .NET Developers due to its awesomeness. Reflector conveniently shows more details about the strong name.

Approach #3: Viewing Strong Name Details with Reflector

You can load an assembly in the free version RedGate’s .NET Reflector and quickly see the strong name details – or lack thereof for non-strong named assemblies. In the image below, see at the bottom where the strong name string is highlighted. Note that the strong name has five parts (though the Culture is optional):

  1. Simple Name or Assembly name without the “.dll” extension (“System.Data” in case of assembly “System.Data.dll”)
  2. Assembly version (“2.0.0.0” in case of “System.Data.dll”)
  3. Culture (“neutral” in case of “System.Data.dll”, but might be “en-us” for US English, or one of many others)
  4. Public Key or PublicKeyToken (public part of the cryptographic public/private key pair used to strong name the assembly, “b77a5c561934e089” in case of “System.Data.dll”)
  5. Processor Architecture – Defines the assembly’s format, such as MSIL (intermediate language) or x86 (binary for Intel x86 processors)

Using Reflector to show strong name

In the next image, see at the bottom where the LACK OF complete name string is highlighted; this assembly does not have a strong name to display, so “Name” field includes a null value for PublicKeyToken. (Note that in the real world, Spring.Core.dll is in fact released as strongly named by the good folks on the Spring.NET project; the screen shot below was done on a non-production version of that DLL.)

Reflector shows missing strong name

While you are at it… make Reflector the default program for “launching” assemblies (actually would need to be for all files ending in the .DLL extension, but Reflector is smart enough to not choke on non-.NET assemblies).

Approach #4: (Bonus!) Viewing Strong Name with Windows Explorer

This post promised three ways to tell if a .NET Assembly has a strong name – but here is a bonus 4th way. Windows Explorer will not show you the strong name characteristics of an assembly, with one exception – for assemblies in the Global Assembly Cache (GAC), strong name data is included in the Properties dialog. If  you are examining the GAC, this can be handy.

Of course, if an assembly is in the GAC at all, it is strongly named by definition; assemblies are required by .NET to be strongly named to be allowed in the GAC.

Strong Naming for Silverlight

Silverlight also has support for strongly named assemblies, which is needed for the Cached Assembly Feature introduced in Silverlight 3.0.

(Silverlight 4 also introduces supports for digital signatures on XAP files, created by signtool.exe, which are validated by the Silverlight runtime for out-of-browser (OOB) applications running with elevated trust.)

Strongly Name Assembly != Digitally Signed Assembly

Strong Names and Digital Signatures are Orthogonal Concerns – Almost

Strongly Naming and Digitally Signing are largely orthogonal concerns. They have different purposes, different tools, and the digital certificates may come from different sources (for publicly distributed binaries, the certs for Digital Signing usually will come from a PKI source, though that is not essential for the Strong Naming certs).

The only dependency among them is that if the Assembly is to be Strongly Named, then the Strong Naming step has to happen before the Digital Signing step.

How do I check whether an assembly is Digitally Signed? You can run the following command to determine whether assembly “foo.dll” is digitally signed:

signtool verify /pa foo.dll

If you want to see the hash – for example, to compare with another assembly’s hash – then you can view it using the following command sequence:

signtool verify /v /pa /ph foo.dll | find "Hash"

Of course, you can use sn.exe and signtool.exe together (one after another) to examine an assembly to ascertain both whether it is strongly named and whether it has been digitally signed.

Strong Names are NOT for Security!

Finally, a word of caution… Strong names are about versioning, not about security. Strong names are more about avoiding DLL Hell (which is largely an accidental concern) than about avoiding hackers (which is deliberate). While a strong name may help alert you to tampering, realize that strong names can be hacked, and Microsoft emphasizes that  strong-named assemblies do not give the same level of trust as digitally signing:

Strong names provide a strong integrity check. Passing the .NET Framework security checks guarantees that the contents of the assembly have not been changed since it was built. Note, however, that strong names in and of themselves do not imply a level of trust like that provided, for example, by a digital signature and supporting certificate.

Consider digitally signing your .NET assemblies if it is important to you or your customers that the origin of the assemblies be traceable and verifiable. One source of digital certificates that can be used for Digitally Signing assemblies is Verisign which has Authenticode Certificates.

See also the response to this comment for more details.

Make Reflector the default action for opening .NET Assemblies in Windows Explorer

Many .NET developers know and love the .NET Reflector tool. If you are one of them, consider making Reflector the default action for when you double-click on (i.e., open) a .DLL file. Just like assigning Microsoft Word to open .DOC files, you can assign a program to open your .DLL files. It is easy… Here are the instructions for Windows 7 – for other versions of Windows the process is similar.

1. Download Reflector and install it; remember where it is installed

2. Using Windows Explorer, navigate to any DLL file on your computer

3. Right-click on the DLL and select “Open with…” from the popup menu

4. From the Caution dialog that appears, select “Open with…” (yes, you have to select it twice, once in step 3, again in step 4):

5. From the dialog that appears, choose the second option – “Select a program from a list of installed programs”:

6. Now you will simply need to choose  the “Browse…” button and navigate to wherever it is you installed Reflector.exe, click the “Open” button and you are done.

Now whenever you want to examine a DLL in Reflector, you can double-click on it from Windows Explorer. If you tool around in the command line like I sometimes will do, you can also launch the DLL in Reflector by just “running” it from the command line like you might do for a .txt document to open it in Notepad.

Realize that Reflector can’t do much with a DLL that is not actually a .NET Assembly, but will handle that case gracefully.