Today, we’re excited to announce Azure SDK 2.8.2 for Visual Studio 2015. This release includes some user interface, validation improvements and engineering optimizations to improve the App Service developer experience. This post will summarize the new features being released in the Azure SDK 2.8.2.
- User interface improvements: We’ve improved the exception-handling logic in the provisioning experience and added UI cues to inform you during the App Service creation process of potential issues that may affect your deployments
- Engineering improvements: Some performance tweaks have been made to improve the overall time-to-provision your App Service app code to Azure, as well as a series of engineering improvements that pave the way for advances in the future
- Azure Resource Management (ARM) template export improvements: ARM template export now drops both the template and parameters files, so the exported files work more effortlessly with the Azure Resource Group Visual Studio project template
App Service tools user interface improvements
Following the Azure SDK 2.8.1 release, which included numerous leaps forward for App Service developers and a wholly redesigned experience, we had some great feedback from customers and teammates that a few minor UI cues and hints would go a long way towards making sure App Service users are able to quickly see if a topology creation had potential issues before they had to see deployment errors. We also took the opportunity to handle those errors more gracefully in the UI. Azure SDK 2.8.2 was our opportunity to create a pit of success for App Service users, and mitigate some obvious scenarios in which users experience issues during app creation.
Improved Resource Group creation cues
One of the assumptions about Resource Group creation we made during the Azure 2.8.1 SDK timeframe was providing a simple textbox for new Resource Groups would be intuitive. Late during testing we realized we could make the new Resource Group experience more obvious. In SDK 2.8.2, we’ve added visual cues to the UI to inform users there’s a clear path to new group creation. The UI auto-selects a Resource Group, but we’ve added a new button providing placeholder text to let users know what’s about to happen.
Mitigating (and handling) deployment errors
What if, during my topology creation for a SQL-backed Web App, I want to create a SQL Server database but mistakenly click the Delete button for the SQL Server resource? This would lead to an ARM template in an invalid state; since the SQL Server Database resource depends on a new (or existing) SQL Server resource, the Azure Resource Manager would disallow the template and result in a deployment error. Instead of allowing me to create this situation in my topology, the App Service tools now inform me that things could get ugly if I try to submit this template.
In the unforeseen case where the management API encounters an issue during provisioning, this same dialog is used, but we provide the exception details in a much more elegant manner than in the previous release. Though this is a contrived example in which a SQL Server was deleted that I intended on using for a new SQL Server database, the UI improvement is obvious – rather than simply “message-boxing” the exception returned from the Azure API, we’re doing more to capture the exceptions gracefully and allow for simple copying the contents of the deeper exception out to a file.
Connection string setup
To ease the out-of-the-box “File - New Project” scenario for ASP.NET developers accustomed to the DefaultConnection connection string defaults that are dropped in our ASP.NET project templates or to make it easy to change the name of the connection string as it’d be in the App Service deployed environment, we’ve added the “Connection String Name” textbox to the SQL Server database provisioning experience.
Through blog post comments, forums, and the Visual Studio Feedback Center, we learned of some hangs during App Service provisioning. We worked with some great customers who were eager to share stack traces confirming some results we’d seen in our own test environments. An upcoming performance optimization already in queue was confirmed to repair the provisioning issue, so we’re excited to announce that the Azure SDK 2.8.2 mitigates this issue and has been fully tested for various deployment scenarios.
We’ve also made tweaks to certain areas of the App Service tooling that allow it to be more intelligent and to give us more abilities to respond to API changes without having to re-ship the entire App Service tooling extension. These features give us the ability to shield customers from minor changes in the APIs that would’ve previously required hotfixes or manual updates. These features, along with other steps we’ve taken towards opening up the “resource cart” idea to other partners, are proving to be exciting components in the future of Azure tooling.
Azure Resource Manager template export improvements
To provide developers an on-ramp to bootstrapping ARM templates In the Azure SDK 2.8.1, we introduced the “Export button,” which allows you to edit the ARM template created in the App Service app creation window. This way, once your topology is setup using the App Service app creation dialog and you’ve finished adding additional resources like SQL databases to your Resource Group, you can easily export the topology in one click.
Now, the export process drops both a template and a separate parameters file, as shown in the Explorer window below.
Once I create a new Azure Resource Group project, I can import the files I exported from the App Service app creation dialog into my new Resource Group project and make changes or setup additional environment-specific parameters files. Once I’m ready to deploy, a simple right-click Deploy on the project will give me the opportunity to execute my ARM template and provision an entirely separate, yet mirrored, environment.
If you don’t already have an Azure account, you can sign-up for a free one and start using all of the above features today. Also, if you’re interested in how simple it can be to get started with your very own pre-built app using Try App Service. Then visit the Azure Developer Center to learn more about how to build apps with it.