Category Archives: Step-by-Step

Four 4 tips for developing Windows Services more efficiently

Are you building Windows Services?

I recently did some work with Windows Services, and since it had been rather a long while since I’d done so, I had to recall a couple of tips and tricks from the depths of my memory in order to get my “edit, run, test” cycle to be efficient. The singular challenge for me was quickly getting into a debuggable state with the service. How I did this is described below.

Does Windows Azure support Windows Services?

First, a trivia question…

Trivia Question: Does Windows Azure allow you to deploy your Windows Services as part of your application or cloud-hosted service?

Short Answer: Windows Azure is more than happy to run your Windows Services! While a more native approach is to use a Worker Role, a Windows Service can surely be deployed as well, and there are some very good use cases to recommend them.

More Detailed Answer: One good use case for deploying a Windows Service: you have legacy services and want to use the same binary on-prem and on-azure. Maybe you are doing something fancy with Azure VM Roles. These are valid examples. In general – for something only targetting Azure – a Worker Role will be easier to build and debug. If you are trying to share code across a legacy Windows Service and a shiny new Windows Azure Worker Role, consider following the following good software engineering practice (something you may want to do anyway): factor out the “business logic” into its own class(es) and invoke it with just a few lines of code from either host (or a console app, a Web Service, a unit test (ahem), etc.).

Windows Services != Web Services

Most readers will already understand and realize this, but just to be clear, a Windows Service is not the same as a Web Service. This post is not about Web Services. However, Windows Azure is a full-service platform, so of course has great support for not only Windows Services but also Web Services. Windows Communication Foundation (WCF) is a popular choice for implementing Web Services on Windows Azure, though other libraries work fine too – including in non-.NET languages and platforms like Java.

Now, on to the main topic at hand…

Why is Developing with Windows Services Slower?

Developing with Windows Services is slower than some other types of applications for a couple of reasons:

  • It is harder to stop in the Debugger from Visual Studio. This is because a Windows Service does not want to be started by Visual Studio, but rather by the Service Control Manager (the “scm” for short – pronounced “the scum”). This is an external program.
  • Before being started, Windows Services need to be installed.
  • Before being installed, Windows Services need to be uninstalled (if already installed).

Tip 1: Add Services applet as a shortcut

I find myself using the Services applet frequently to see which Windows Services are running, and to start/stop and other functions. So create a shortcut to it. The name of the Microsoft Management Console snapin is services.msc and you can expect to find it in Windows/System32, such as here: C:\Windows\System32\services.msc

A good use of the Services applet is to find out the Service name of a Windows Service. This is not the same as the Windows Services’s Display name you seen shown in the Name column. For example, see the Windows Time service properties – note that W32Time is the real name of the service:

Tip 2: Use Pre-Build Event in Visual Studio

Visual Studio projects have the ability to run commands for you before and after the regular compilation steps. These are known as Build Events and there are two types: Pre-build events and Post-build events. These Build Events can be accessed from your Project’s properties page, on the Build Events side-tab. Let’s start with the Pre-build event.

Use this event to make sure there are no traces of the Windows Service installed on your computer. Depending on where you install your services from (see Tip 3), you may find that you can’t even recompile your service until you’ve at least stopped it; this smooths out that situation, and goes beyond it to make the usual steps happen faster than you can type.

One way to do this is to write a command file –  undeploy-service.cmd – and invoke it as a Pre-build event as follows:

undeploy-service.cmd

You will need to make sure undeploy-service.cmd is in your path, of course, or else you could invoke it with the path, as in c:\tools\undeploy-service.cmd.

The contents of undeploy-service.cmd can be hard-coded to undeploy the service(s) you are building every time, or you can pass parameters to modularize it. Here, I hard-code for simplicity (and since this is the more common case).

set ServiceName=NameOfMyService
net stop %ServiceName%
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\installutil.exe /u %ServiceName%
sc delete %ServiceName%
exit /b 0
Here is what the commands each do:
  1. Set a reusable variable to the name of my service (set ServiceName=NameOfMyService)
  2. Stop it, if it is running (net stop)
  3. Uninstall it (installutil.exe /u)
  4. If the service is still around at this point, ask the SCM to nuke it (sc delete)
  5. Return from this .cmd file with a  success status so that Visual Studio won’t think the Pre-Build event ended with an error (exit /b 0 => that’s a zero on the end)
In practice, you should not need all the horsepower in steps 2, 3, and 4 since each of them does what the prior one does, plus more. They are increasingly powerful. I include them all for completeness and your consideration as to which you’d like to use – depending on how “orderly” you’d like to be.

Tip 3: Use Post-Build Event in Visual Studio

Use this event to install the service and start it up right away. We’ll need another command file – deploy-service.cmd – to invoke as a Post-build event as follows:

deploy-service.cmd $(TargetPath)

What is $(TargetPath) you might wonder. This is a Visual Studio build macro which will be expanded to the full path to the executable – e.g., c:\foo\bin\debug\MyService.exe will be passed into deploy-service.cmd as the first parameter.  This is helpful so that deploy-service.cmd doesn’t need to know where your executable lives. (Visual Studio build macros may also come in handy in your undeploy script from Tip 2.)

Within deploy-service.cmd you can either copy the service executables to another location, or install the service inline. If you copy the service elsewhere, be sure to copy needed dependencies, including debugging support (*.pdb). Here is what deploy-service.cmd might contain:

set ServiceName=NameOfMyService
set ServiceExe=%1
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\InstallUtil.exe %ServiceExe%
net start %ServiceName%
Here is what the commands each do:
  1. Set a reusable variable to the name of my service (set ServiceName=NameOfMyService)
  2. Set a reusable variable to the path to the executable (passed in via the expanded $(TargetPath) macro)
  3. Install it (installutil.exe)
  4. Start it (net start)
Note that net start will not be necessary if your Windows Service is designed to start automatically upon installation. That is specified through a simple property if you build with the standard .NET template.

Tip 4: Use System.Diagnostics.Debugger in your code

If you follow Tip 2 when you build, you will have no trouble building. If you follow Tip 3, your code will immediately begin executing, ready for debugging. But how to get it into the debugger? You can manually attach it to a running debug session, such as through Visual Studio’s Debug menu with the Attach to Process… option.

I find it is often more productive to drop a directive right into my code, as in the following:

void Foo()
{
int x = 1;
System.Diagnostics.Debugger.Launch(); // use this…
System.Diagnostics.Debugger.Break();    // … or this — but not both
}

System.Diagnostics.Debugger.Launch will launch into a into debugger session once it hits that line of code and System.Diagnostics.Debugger.Break will break on that line. They are both useful, but you only need one of them – you don’t need them both – I only show both here for illustrative purposes. (I have seen problems with .NET 4.0 when using Break, but not sure if .NET 4.0 or Break is the real culpret. Have not experienced any issues with Launch.)

This is the fastest way I know of to get into a debugging mood when developing Windows Services. Hope it helps!

Cure for “NO INSTALLATION MEDIA” Error when Zune Installer Can’t Find the Media for Installation Package

How I got around Zune’s “NO INSTALLATION MEDIA” and “Can’t Find the Media for Installation Package” error

 I recently reinstalled Windows 7 on one of my computers and in rebuilding my development tool set, including for Windows Phone, and found I could not run a Windows Phone 7 project locally: Visual Studio complained I did not have the Zune software installed. Okay, not a problem; I will install Zune. But not so fast…

I encountered the following mysterious error while trying to install the Zune software to my Windows 7 desktop.

What does this Zune error message mean?

 
Looking at the text of the message did not help me or yield obvious clues:

NO INSTALLATION MEDIA

Can’t find the media for installation package ‘Windows Media Format SDK’. It might be incomplete or corrupt.

Error code: 0x80070002

Searching around the internets did not help, though I saw a reference to do a few things, one of which was to install the latest Windows Media Player. Well… it turns out, I had NO version of the Windows Media Player installed, so I simply installed the latest, and the Zune installer was happy…

One more step

But Visual Studio 2010 was NOT yet willing to allow me to run the Windows Phone 7 emulator to test and debug my Windows Phone applications. I saw the following additional (but improved!) errors from Visual Studio.

First, could not deploy. Nothing new here:

But the reason provided looked more promising:

This is a better known error, easily rectified. Simply switch to the emulator if your project is referencing an attached device, done at the top of Visual Studio as shown here:

Okay… now back to Windows Phone 7 development – of course, with a Windows Azure back-end using the Windows Azure Toolkit for Windows Phone 7.

4 Reasons to embrace the “www” subdomain prefix in your Web Addresses, and how to do it right

In support of the www subdomain prefix

For web addresses, I used to consider the “www” prefix an anachronism and argued that its use be deprecated in favor of the plain-old domain. In other words, I used to consider forms such as bostonazure.org superior to the more verbose www.bostonazure.org.

I have seen the light and now advocate the use of the “www” prefix – which is technically a  subdomain – for clarity and flexibility. I now consider www.bostonazure.org superior to the overly terse bostonazure.org.

I am not alone in my support of the www subdomain. Not only is there a “yes www” group – found at www.yes-www.org – advocating we keep using the www prefix, there is also an “extra www” group – found at www.www.extra-www.org [sic] – advocating we go all in and start using two sets of www prefixes. While I’m not ready to side with the extra www folks (which would give us www.www.bostonazure.org), for those who do, you might want to know they offer the following nifty badge for your displaying pleasure.

image

While use of two “www” prefixes may one too many, here are 4 reasons to embrace a single “www’ prefix, followed by 2 tips on how to implement it correctly.

Four reasons to embrace the www prefix

traffic light

Reason #1: It’s a user-friendly signal, even if occasionally redundant

The main, and possibly best, reason is that it is user-friendly. Users have simply come to expect a www prefix on web pages.

The “www” prefix provides a good signal. You might argue that it is redundant: Perhaps the http:// protocol is sufficient? Or the “.com” at the end?

First, consider that the http:// protocol is not always specified; it is common to see sites advertised in the form www.example.com.

Second, consider that the TLD (top-level-domain) can vary – not every web site it a “dot com” – it might be a .org, .mil, or a TLD from another country – many of which may not be obvious as web addresses for the common user without a www prefix, even with the http:// protocol.

Third, consider that even if there are cases where the www is redundant, that is still okay. An additional, familiar signal to humans letting them know with greater confidence that, yes, this is a web address, is a benefit, not a detriment.

Today, most users probably think that the Web and the Internet are synonymous anyway. To most users, there is nothing but the www – we need to realize that today’s Internet is inhabited by regular civilians (not just programmers and hackers).  Let’s acknowledge this larger population by utilizing the www prefix and reducing net confusion (pun intended).

Reason #2: Go with the flow

The application and browser vendors are promoting the www prefix.

Microsoft Word and Microsoft Outlook – two of the most popular applications in the world – both automatically recognize www.bostonazure.org as a web address, while neither automatically recognizes bostonazure.org. (Both also auto recognize http://bostonazure.org.) Other text processing applications have similar detection capabilities and limitations.

Browsers also assume we want the www prefix; in any browser, type in just “twitter” followed by Ctrl-Enter – the browser will automatically put “http://www.” and append “.com” forming “http://www.twitter.com” (though then we are immediately redirected to http://twitter.com). [Note that browsers typically are actually configured to append something other than “.com” if that is not the most common TLD there; country specific settings are in force.] For the less common cases where you are typing in a .org or other non-default setting, the browser can only be so smart; you need to type some in fully on your own.

Reason #3: Advantages on high volume sites

While I have been aware of most of the raw material used in this blog post for years, this one was new to me.

High traffic web sites can get performance benefits by using www, as described in the Yahoo! Best Practices for Speeding Up Your Web Site, though there is a workaround (involving an additional images domain) that still would allow a non-www variant, apparently without penalty.

Reason #4: Azure made me do it!

It turns out that Windows Azure likes you to use the www prefix, as described by Steve Marx in his blog post on custom domain names in Azure. This appears to be due to the combined effects of how Azure does virtualization for highly dynamic cloud environments – plus limitations of DNS.

In fact, it was this discovery that caused me to rethink my long-held beliefs around the use of www. Though I didn’t find any posts that specifically viewed this exactly like I did, my conclusion is the following:

I concluded the Internet community has changed over the years and is now dominated by non-experts. The “www” affordance inserted into the URLs makes enough of a difference in the user experience for non-expert users that we ought to just use the prefix, even if expert users see it as redundant and repetitive – as I used to.

In other words, nobody is harmed by use of the www prefix, while most users benefit.

Two tips to properly configure the www prefix

One of the organizations promoting dropping the www – http://no-www.org/ – describes three classes of “no www” compliance:

  • Class A: Do what most sensible sites do and allow both example.com and www.example.com to work. This is probably the most easily supported in GoDaddy, and probably the most user-friendly, since anything reasonable done by the user just works.
  • Class B: Redirect traffic from example.com to www.example.com, presumably with a 301 (Permanent) http redirect; this approach is most SEO/Search Engine-friendly, while maintaining similar user-friendliness to Class A.
  • Class C: Have the www variant fail to resolve (so browser would give an error to the user attempting to access it). This is not at all user friendly, but is SEO-friendly.

So what are the two rules for properly configuring the www prefix?

Tip #1: Be user- and SEO-friendly with 301 redirect

Being user-friendly argues for Class A or Class B approach as mentioned above.

You don’t want search engines to be confused about whether the www-prefixed or the non-www variant is the official site. This is not Search Engine Optimization (SEO)-friendly; it will hurt your search engine rankings. This argues for Class B or Class C approach as mentioned above.

For the best of both worlds, the Class B approach is the clear winner. Set up a 301 permanent http redirect from your non-www domain to your www-prefixed variant.

You can set this up in GoDaddy with the Forward Subdomain feature in Domain Manager, for example.

You can also set it up with IIS :

Or with Apache:

Tip #2: Specify your canonical source for content

While the SEO comment above covers part of this, you also want to be sure that if you are on a host or environment where you are not able to set up a 301 redirect, you can at least let the search engines know which variant ought to get the SEO-juice.

In your HTML page header, be sure to set the canonical source for your content:

<head>
    <link rel="canonical" href="http://www.bostonazure.org/" />
    ...
</head>

Google honors this currently:

Google is even looking at cross-domain support for canonical tag (though other search engines have not announced plans for cross-domain support):

From an official Bing Webmaster blog post from Feb 2009, Bing will support it:

Reportedly, Bing and Yahoo! are not yet supporting this very well:

But it appears Bing and Yahoo! have either just implemented it, or perhaps they are about to:

You can also configure Google Webmaster Tools (and probably the equivalents in Bing and Yahoo!) to say which variant you prefer as the canonical source.

Unusual subdomain uses

There are some odd uses of subdomain prefixes. Some are designed to be extremely compact – such as URL shortening service bit.ly. Others are plain old clever – such as social bookmarking site del.i.cio.us. Still others defy understanding – in the old days (but not *that* old!), I recall adobe.com did not resolve – there was no alias or redirect, just an error – if you did not type in the www prefix, you were out of luck.

Another really interesting case of subdomain shenanigans is still in place over at MIT where you will find that www.mit.edu and mit.edu both resolve – but to totally different sites! This is totally legal, though totally unusual. There is also a web.mit.edu which happens to match mit.edu, but www.mit.edu is in different hands.

In the early days of the web, the Wall Street Journal was an early adopter and they used to advertise as http://wsj.com. These days both wsj.com and www.wsj.com resolve, but they both redirect to a third place, online.wsj.com. Also totally legal, and a bit unusual.

[edit 11-April-2012] Just noticed this related and interesting post: http://pzxc.com/cname-on-domain-root-does-work [though it is not http://www.pzxc.com .. :-)]

Credit for Traffic Light image used above:

  1. capl@washjeff.edu
  2. http://capl.washjeff.edu/browseresults.php?langID=2&photoID=3803&size=l
  3. http://creativecommons.org/licenses/by-nc-sa/3.0/us/
  4. http://capl.washjeff.edu/2/l/3803.jpg

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 https://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.

Getting Started with Windows Azure Development

This is an update from an old post on Azure Development Requirements, this time focused on a reasonable stack of tools for Azure development. (The structure is based on list from Jason Haley which he prepared for a talk to the April 29, 2010 meeting of the Boston Azure cloud computing user group.)

How-To Configure an Azure Development Environment

0. Operating System Running IIS 7.x

No way of getting around the need for a Windows operating system that runs IIS 7.0 or IIS 7.5 — either directly or indirectly (see note below on using virtualization).

The operating system versions that support IIS 7.0 include:

  • Vista Business Edition and Ultimate

The operating system versions that support IIS 7.5 include:

What happens if I don’t have Vista, Win 7, or Server 2008?

There is one other hope. Use Virtual PC (or your favorite virtualization solution) and run an instance of a supported operating system in a virtual mode. (This blog post on creating a virtual machine image for Windows 7 using Virtual PC 2007 may help.)

Once you have an operating environment – real or virtual – the rest is the same.

How do I enable IIS 7.x to run?

If you are running a desktop version of Windows (Vista or Windows 7), it is likely you need to enable IIS through the control panel. Here are step-by-step instructions for enabling IIS 7.5 on Windows 7.

If you are doing this to prepare for the April 29 Boston Azure or the May 8th Firestarter meeting, please make sure you have enabled IIS7 with ASP.NET and have WCF HTTP Activation enabled.

1. Visual Studio

You need a copy of Visual Studio that supports Azure development. Currently your options are Visual Studio 2008 SP1Visual Studio 2010 (many editions), and Visual Web Developer 2010 Express Edition.

If you don’t know which version of Visual Studio to install, go with Visual Web Developer 2010 Express Edition (which is also free).

2. Windows Azure Tools and SDK

Download and install Windows Azure Tools for Microsoft Visual Studio 1.1 (Feb 2010) – this includes the Windows Azure SDK (and its samples)

Pay special attention to the first note at the top of that post:

Visual Studio must be run as an Administrator

You must run Visual Studio with elevated permissions when building Cloud Services for Windows Azure.

It is possible to create a shortcut that will launch Visual Studio with administrative permissions by setting the “Run as Administrator” checkbox in the Advanced Properties page of the Shortcut tab; this is available from the Properties menu option off of the context menu.

3. Microsoft SQL Server

A local installation of SQL Server is needed for local development work involving SQL Azure, Azure Table Storage, or Azure queues.

You only need to do this step if you didn’t install a version of SQL Server during Step 1 (above) while installing Visual Studio.

If you do not have a paid license for SQL Server, your best bet is to download a free copy of either Microsoft SQL Server 2005 Express or Microsoft SQL Server 2008 Express.

If you don’t know which version of SQL Server to install, go with Microsoft SQL Server 2008 Express (which is also free).

4. Windows Azure Platform Training Kit

At least for the April Boston Azure meeting, you will  also need the Windows Azure Platform Training Kit (Dec 2009 update) since Jason Haley (the main speaker) will assume we have this installed so he can reference it during the meeting.

5. Future Optional Extra Credit Tools

Once you have deployed to the cloud, you may also be interested in:

  • Fiddler (for IE) and Firebug (for Firefox) to spy on http traffic going back and forth to a deployed Azure app
  • What else?

6. Do You Have a Token?

If you are lucky enough to have a token for free (though time-limited) access to Azure services in the cloud, here’s How to Redeem an Azure Token.

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.