Over the last year, we’ve built a few Azure-hosted applications (including our own web site). Throughout that time, we’ve hit a few walls, suffered setbacks and learned a ton about how to work with both the service and the Azure SDK tools (including the sometime challenge of dealing with version differences with both the SDK and the Azure management interface).
Since we’ve been helped by the many folks that post to twitter and their own blogs, we’re hoping to return the favor to the larger community. Here are a few of the initial challenges we ran into and how we solved them. In all cases, your mileage may vary. Certainly if you have feedback, a better way to do things or something else (related), please do comment. We’ll be publishing a follow-up post with additional solutions in the coming months.
NOTE: This post was written with the assumption of Visual Studio 2012 and Windows 8, along with the v1.8 release of the Azure tools. We’ve seen posts referencing similar problems with older tools, but these tips may be less helpful unless you’re using the same versions.
Error when publishing applications
This particular issue is fairly non-descript, since it encompasses a whole range of causes and subsequent actions on your part. However, problems with publishing happened frequently enough that it caused some serious delays in getting new builds of applications out to the cloud. The following are the ones that caught us most frequently.
Administrator Rights
In order to debug or publish, you need to start Visual Studio “as Administrator” or you’ll get an error stating that the current user has insufficient privileges. The solution is to right click on the Visual Studio shortcut and pick “Run as Administrator” to fix this problem. If you’ve pinned VS to your task bar (like I do), just right click once on the task bar item, right click again on the main Visual Studio link and then pick “Run as Administrator.”
Out of Memory
When either trying to publish your solution directly to Azure or simply trying to create a package, you may receive an error that is simply “Out of Memory Exception.” Apparently, with only 4 Gb of RAM available, Visual Studio is unable to create the Azure deployment package. It’s really unclear to me why so much memory is necessary, but often without a clean restart of Visual Studio, I get this message. The solution is simple, close down all other applications, restart Visual Studio and try again. I can occasionally get away without these steps, but if I’ve been debugging or opening lots of other applications, I can guarantee my publish/packaging operation won’t work. I never had to restart Windows, just exit VS and start again.
Unknown Error
In the midst of publishing a package (after initiating the “update” on a cloud service), you get an error from the Azure web-based management console that states your update was unsuccessful. For me, this usually happened after several minutes of waiting for the package to upload, then cycling the instances and, at the last minute, erroring out. When pressed for additional details (by clicking that not-so-helpful “I” icon), there are no details. This happened to me recently and it was the result of having both http and https endpoints defined, but without the SSL certificate referenced by the service configuration setting loaded into the target subscription (the client we were working with used multiple subscriptions to separate “production” from “QA”).
In this case, the production environment had the SSL certificate loaded, but the QA environment did not. Because my Azure settings listed the thumbprint for the SSL certificate and both end points were defined, the update failed in QA, while successful in production. Unfortunately, it was difficult to figure out the root cause since the management console didn’t give any details.
Only after I looked in the log, click on the “failed” entry and then clicked the “I” details button at the bottom of the interface, did I realize the missing cert was the culprit. Embarrassingly, it took a call to Microsoft support to figure out that the additional detail was indeed available, but double-clicking the log entry doesn’t work. You have to click on the details button at the bottom of the page to get additional XML-based information regarding the entry.
If the SSL certificate isn’t your issue, the logs should help you figure out what is and provide more insight into the failed update.
Unable to manage subscription
More often than not, being able to manage a subscription is due to the lack of a management certificate, the fact that your Microsoft ID (aka LiveID) hasn’t been granted co-administrator rights (assuming you didn’t create the subscription) OR you’ve got a filter set.
The last one is the easiest to fix. You set your subscription filter at the top of the management interface. Just click the little funnel and then check or uncheck the subscriptions you want to see. Occasionally, you’ll forget that you’ve unchecked a subscription you’d like to see OR someone will add you as co-admin on a subscription you need to work with, but don’t see it because of a previous filter setting (don’t ask me how I know this). So, if you can’t see the subscription, just check your filter settings.
If you’re not filtering your subscriptions, the owner/primary administrator may have not added your Microsoft (Live) ID to the subscription. In this case, there’s nothing you can do, but ask them to add you.
Finally, Azure requires various certificates to be loaded into the subscription to allow you to perform various functions. These certificates are shown in two places: 1) in the settings section under “Management Certificates” and within Cloud Services under “Certificates.”
In both cases, you can upload your certificates manually through the interface. However, the certificates have to be .CER type, not the .PFX (read about the different certificate formats for Azure here – NOTE: the older management interface for Azure is shown, but the basics should still work). For the certificates required for Remote Desktop, you can create them dynamically through the Azure tools in Visual Studio. This is done by choosing the “Configure Remote Desktop” option after right-clicking on your Azure Deployment project. Clicking on the dropdown list box will show you existing certificates or allow you to create a new one.
After you publish, the new RDP certificate will be uploaded automatically.
Deploying different configuration settings
The Visual Studio tools are pretty decent and give you a degree of flexibility for deploying various environment-specific settings to your Azure subscription. However, getting the hang of setting the various values took a bit. Hopefully, if you’re challenged as I was, the following will help.
Generally, when developing an ASP.NET application, you have the option to create various build configurations directly in Visual Studio. Each configuration is accompanied by a web.config transformation. Each transformation is a derivative of the core web.config file, with specific XML-transformation directives to update, replace or delete various nodes within the file. With Azure, these build configurations are handled exactly the same way, except that when you build a deployment package, you pick the configuration you want at the time you build the package; you don’t have to change the Configuration Manager setting.
In addition to build configurations, there are Azure-specific “service” configuration settings. Much like adding Web.Config transformations, you can create various Azure service configurations, which allow you to stipulate variables like a blob storage account, certificate thumbprints, number of instances or what SMTP server to use (very similar to the AppSettings node in web.config). Azure service configurations and build configurations are complementary. However, build configurations (and the associated web.config settings) can only be changed when you upload a new build to the Azure environment. Conversely, some service configuration settings can be changed through the Azure management interface (after deployment or at run-time), making them more flexible. This is particularly handy when you have to make somewhat trivial application setting changes that would require a re-publish if the setting were housed in the web.config file (yes, yes. You could RDP to the box, but it’s still easier to access the Azure Management console).
The various service configurations are managed through the Settings interface for your Azure project. Set the drop down to “All Configurations” to establish the range of settings across service configurations. If you click on Settings, for example, you will then see the range settings for your Azure deployment. Each setting, while in the All Settings, any configuration setting that is configuration-specific is shown with a “select configuration” value. Any setting that is common, simply displays the value. While in “All Configurations” you can add or remove settings across all configurations.
To change a setting for a particular configuration, just change the drop down value to the configuration you want and then click in the “Value” field of the setting. Enter the new value and you’re done (don’t forget to save). NOTE: You can add or remove settings within a specific configuration, so you’ll need to plan your setting approach so that all settings make sense for all configurations.
When you package up your application, you’ll be prompted to select the build configuration, as well as the service configuration. This will combine the specific web.config transformations along with service settings for the deployment you want to publish.
More information can be found on Microsoft’s site: http://msdn.microsoft.com/en-us/library/windowsazure/ff683672.aspx
Finding that cursed subscription ID
As Azure has evolved, Microsoft has updated the management interface. Where finding the subscription ID was relatively simple in early versions, later versions “hid” the subscription ID (for certain workloads) until after you publish for the first time. If you’re also having trouble publishing, this is a double-whammy.
In truth, the subscription ID is always visible, though I’d argue the interface makes it a challenge to find if you’re unfamiliar with the management console. To find you subscription ID, just log onto http://windows.azure.com with your LiveID. Then click on the Settings menu item on the left (it’s the little gear thing). Now, click on Administrators on the top menu. This is the list of all administrators for your subscription. Next to each individual, you’ll see the subscription name and the ID. Just copy the ID from this interface. If the column isn’t wide enough, just click and drag the column separator on the right.
Hopefully these tips will help you avoid challenges with Azure. However, I’m certainly interested in your feedback. If you have some, please comment.
Other Resources
Visual Studio and Azure: http://msdn.microsoft.com/en-us/library/windowsazure/ee405484.aspx
Setting up Remote Desktop for Azure Cloud Service: http://msdn.microsoft.com/en-us/library/windowsazure/ee405484.aspx
Running multiple web sites in an Azure web role: http://msdn.microsoft.com/en-us/library/windowsazure/ee405484.aspx
Collecting and logging data by using Azure Diagnostics: http://msdn.microsoft.com/en-us/library/windowsazure/ee405484.aspx
No comments:
Post a Comment