Wade Wegner

Earlier this week we released the Windows Azure SDK 1.6, which includes a lot of great updates to the emulators, tools for Visual Studio, and libraries. One of my favorite additions is a new way to get a management certificate installed into Windows Azure and onto your machine. You can now browse to https://windows.azure.com/download/publishprofile.aspx and login with your Live ID; this process will do two things:

1. Generate a management certificate that is installed into Windows Azures on your behalf.
2. Prompts you to download a .publishsettings file which includes an encoded version of your certificate and all of your subscription IDs.

The new tools for Visual Studio let you easily important this file and immediately start working with your subscriptions from within Visual Studio. It’s a much simpler experience than in the past. In fact, on this weeks episode of the Cloud Cover Show (not yet published) Steve and I cover how to use this file from within your own code. While Steve beat me to it and published a great blog post showing some of the things you can do, I thought I’d take this a slightly different way and show you a couple different things:

• How to install the certificate into your personal certificate store (which is exactly what Visual Studio is doing).
• How to use the certificate from your person certificate store to make calls to the Service Management API.

The code is very similar. Take a look:

var publishSettingsFile =
    @"C:\\temp\\CORP DPE Account-11-16-2011-credentials.publishsettings";

XDocument xdoc = XDocument.Load(publishSettingsFile);

var managementCertbase64string =
    xdoc.Descendants("PublishProfile").Single().Attribute("ManagementCertificate").Value;

var importedCert = new X509Certificate2(
    Convert.FromBase64String(managementCertbase64string));

Now that we’ve imported the certificate, we can extract some information. I’ll grab the certificate thumbprint, which uniquely identifies the certificate—we’ll use it later in the post.

string thumbprint = importedCert.Thumbprint;

Additionally, I can grab my subscription ID from the .publishsettings file – this we will also use later.

string subscriptionId = xdoc.Descendants("Subscription").First().Attribute("Id").Value;

Now, we can take our X509Certificate2 and install it directly into our certificate store.

X509Store store = new X509Store(StoreName.My);
store.Open(OpenFlags.ReadWrite);
store.Add(importedCert);
store.Close();

After running this code, you can see that the certificate has been installed into my personal certificate store.

If you select the certificate you’ll see that it’s the same certificate with the same thumbprint.

Since the certificate is now loaded into the certificate store I can delete the .publishsettings file – I no longer need it. (It’s also a credential that I don’t want to let anyone else get their hands on.)

Now I have the following resources available to me:

• My X509 certificate loaded in my personal certificate store.
• The thumbprint for the certificate (which we’ll use to identify the right certificate).
• My Windows Azure subscription ID.

With this information we can do the exact same thing Steve shows in his post except without the .publishsettings file.

X509Store store = new X509Store(StoreName.My);
store.Open(OpenFlags.ReadWrite);
X509Certificate2 managementCert =
    store.Certificates.Find(X509FindType.FindByThumbprint, thumbrprint, false)[0];

var req = (HttpWebRequest)WebRequest.Create(
    string.Format("https://management.core.windows.net/{0}/services/hostedservices",
    subscriptionId));

req.Headers["x-ms-version"] = "2011-10-01";
req.ClientCertificates.Add(managementCert);

XNamespace xmlns = "http://schemas.microsoft.com/windowsazure";

Console.WriteLine(string.Join("\n",
    XDocument.Load(req.GetResponse().GetResponseStream())
    .Descendants(xmlns + "ServiceName").Select(n => n.Value).ToArray()));

Essentially, we can grab the certificate out of the certificate store using the thumbprint and then make the exact same call to the service management API.

The console output below shows that I’m able to get a list of all my hosted services:

It’s as simple as that!

I’m not sure that this post applies to everyone—in fact, most of you may find it boring or cryptic—but for those of you that are building content or tools you’ll probably find this a really simple way to automate a lot of the pieces. I know that my team plans to use these techniques in a lot of places to simply the experience of getting started with Windows Azure.

I hope this helps!

Now that we can get our hands on the Windows Developer Preview of Windows 8, I’m sure everyone is excited to start building applications! For many of us, this means that we’ll want to install all of the great Windows Azure tools on our Windows Developer Preview machine – especially if we plan to take advantage of the new Windows Azure Toolkit for Windows 8. However, there are a few things we’ll need to do in order to get things to work.

Quickly let me explain the three challenges you’ll run into:

1. The current Windows Azure Tools for Visual Studio do not yet support Dev11 – you’ll have to install Visual Studio 2010.
2. There are a few quirks getting dependencies for IIS installed on Windows 8 using the Web Platform Installer.
3. After Visual Studio 2010 and the Windows Azure Tools for Visual Studio are installed on a machine with Dev11, the Windows Azure tools will grab an environmental path variable that points to 11.0 instead of 10.0.

Fortunately, these things are pretty easy to resolve and will certainly get addressed in later builds.

Here’s what you’ll have to do to get the tools and SDK working with the Windows Developer Preview:

1. Install Microsoft .NET Framework 3.5.1. Easiest way is to type “Windows Features”, select Settings, and select Turn Windows features on or off. Then simply check the checkbox. Click OK to install.
   
2. Next we need to correctly configure IIS. Typically we’d do this through the Web Platform Installer, but this doesn’t work correctly on Windows 8. From Turn Windows features on or off you’ll need to do the following, then click OK to install.
   • Check Internet Information Services.
   • Expand Internet Information Services and World Wide Web Services.
   • Expand Application Development Features and check ASP.NET 2.0, ASP.NET 4.5, and CGI.
   • Expand Common HTTP Features and check HTTP Redirection.
   • Expand Health and Diagnostics and check Logging Tools, Request Monitor, and Tracing.
3. Install the Web Platform Installer (WebPI).
4. Install Visual Web Developer 2010 Express through WebPI. (You can use a different version of Visual Studio 2010, so long as it’s supported by the Windows Azure Tools for Visual Studio.)
5. Install Windows Azure Tools for Microsoft Visual Studio 2010 – September 2011 through WebPI.

Okay, now you have everything installed. However, before you trying running Visual Studio, you have to create a script to launch Visual Studio 2010. This is because the Windows Azure tools use an environmental variable that’s incorrectly pointing to version 11.0, and we’ll need to change it right before we launch to version 10.0 (for Visual Studio 2010).

@ECHO OFF

SET VisualStudioVersion=10.0

SET VisualStudioPath="%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\Common7\IDE"
IF NOT EXIST %WINDIR%\SysWow64 SET VisualStudioPath="%ProgramFiles%\Microsoft Visual Studio 10.0\Common7\IDE"

CD /D %VisualStudioPath%

VWDExpress.exe

As you can see, the script changes the VisualStudioVersion to 10.0 then launches Visual Web Developer Express (there’s a little extra code to set the path correctly regardless of 32- or 64-bit versions of Windows).

Save the above script as a CMD file (i.e. OpenVisualStudio2010.cmd) and then make sure to right-click and Run as administrator! If you forget to run the script as administrator then Visual Studio won’t have the permissions needed to run the Windows Azure tools correctly.

Look, it’s working!

NOTE: I found myself having to reboot Windows 8 in order to resolve a problem where the debugger wouldn’t attach. Not sure if this occurs every time, but in case you have a similar issue just try rebooting.

I hope this helps!

Yesterday Steve Marx and I covered the new Windows Azure Tools for Visual Studio 1.4 release on the Cloud Cover Show (will publish on Friday, 8/5). Since the tools shipped the same day as the show we literally only had an hour or so before the show to pull together a demonstration of some of the new capabilities. I think we did a reasonably good job, but I’d like to further clarify a few things in this post.

For a complete look at the updated tools, I recommend taking a look at posts by Technical Evangelists Nathan Totten and Nick Harris.  Additionally, you should review the release documentation on MSDN.

One of the items I demonstrated on the show was deploying the new MVC 3 template to Windows Azure.

It’s great having this template built into the tools. No longer do I have to hit Steve Marx’s website to lookup the requisite MVC 3 assemblies.

Immediately after creating the projects I confirmed that my assemblies were all added and set to Copy Local = True by default (one of the nice aspects of having the template baked into the tools) and published to Windows Azure.  I was a bit surprised when suddenly I got the YSOD:

Naturally, I updated my web.config file with <customErrors mode="Off" /> and redeployed to Windows Azure.

In case you don’t want to click the image, the error is:

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 – Error Locating Server/Instance Specified)"

In retrospect, I should have expected this error as I received validation warnings within Visual Studio (one of the other nice updates in the 1.4 tools):

I was quite baffled as to why MVC 3 suddenly would require SQL Express (or any flavor of SQL for that matter), until Anders Hauge—a PM on the Visual Studio team—clued me in on the fact that they have shipped the ASP.NET Universal Providers within the MVC 3 template.

For information on these providers, see Introducing System.Web.Providers – ASP.NET Universal Providers for Session, Membership, Roles and User Profile on SQL Compact and SQL Azure by Scott Hanselman for a great introduction.

It turns out that, by default, the template uses the default session state provider in ASP.NET Universal Providers as the ASP.NET session state provider, which in turn uses SQL Express (by default) to store session state.

<sessionState mode="Custom" customProvider="DefaultSessionProvider">
  <providers>
    <add name="DefaultSessionProvider"
         type="System.Web.Providers.DefaultSessionStateProvider, System.Web.Providers, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
         connectionStringName="DefaultConnection"
         applicationName="/" />
  </providers>
</sessionState>

Okay, so what’s the best way to get this to work?

Well, in my haste on the Cloud Cover Show, I simply uninstalled the ASP.NET Universal Provider package, which removed the custom session state provider.  Of course, once I deployed, I no longer saw the YSOD.  This is probably not the best way to go about fixing this, as the ASP.NET Universal Providers are really worth using. For a good analysis of the options, take a look at Nathan’s discussion on various ways to resolve this in his post Windows Azure Tools 1.4 Released.

In retrospect, I wish I had simply created a SQL Azure database and used it instead.  It’s pretty easy to do:

1. In the Windows Azure Platform Management Portal, select Database and create a new database.  I called mine UniversalProviders.

   

2. Select the database and click the View … button to grab/copy your connection string. Note: you’ll need to remember your SQL login password.

   

3. In your solution, update the ApplicationServies and DefaultConnection connection strings using your SQL Azure connection string. Note: you must set MultipleActiveResultSets=True in the connection string, so be sure to add it back if you’ve copied the SQL Azure connection string from the portal.

   <connectionStrings>
     <add name="ApplicationServices"
          connectionString="Server=tcp:YOURDB.database.windows.net,1433;Database=UniversalProviders;User ID=YOURLOGIN@YOURDB;Password=YOURPWD;Trusted_Connection=False;Encrypt=True;MultipleActiveResultSets=True;"
          providerName="System.Data.SqlClient" />
     <add name="DefaultConnection"
          connectionString="Server=tcp:YOURDB.database.windows.net,1433;Database=UniversalProviders;User ID=YOURLOGIN@YOURDB;Password=YOURPWD;Trusted_Connection=False;Encrypt=True;MultipleActiveResultSets=True;"
          providerName="System.Data.SqlClient" />
   </connectionStrings>
   

4. Deploy to Windows Azure.

Now, when we run the applications, it works!

In fact, I recommend you use Database Manager from the portal …

… to open up the database and see that, in fact, you now have a dbo.Sessions table in the database.

What’s more, if you then click Log On and setup a user, you’ll see all the membership & roles work within the MVC application in Windows Azure!

Wrapping up, apologies for not digging into this in greater depth on the show – hopefully this post helps to clarify a few things.