Today, we’re excited to announce Azure SDK 2.8.1 for Visual Studio 2013 and Visual Studio 2015. This SDK update offers some great new features for Azure App Service developers to complement the new release of App Service API Apps and general availability of Mobile Apps .NET server SDK. With these service and tooling updates fresh on heels of the recent updates to the ASP.NET 5 RC, it’s an exciting time to be developing your Web, Mobile, and REST APIs in Azure. This post will summarize the new features being released in the Azure SDK 2.8.1.
- A new modern App Service creation experience: We’ve re-imagined and re-designed the entire App Service tooling, and taken significant steps in unifying the app creation and publishing experiences for Web, Mobile, and API app developers.
- Project template updates for API and Mobile Apps: To support developers who want to make use of the recent updates for REST API and mobile developers we’ve updated the Visual Studio templates.
- Resource Manager template export: The new tools provide one-click JSON file export of the resources you’re about creating so you can re-create your topologies in other resource groups or even other Azure subscriptions.
- Improved REST API client generation: Simplified user experience and underlying code generation improvements provided by the Azure SDK team’s open-source Swagger-based generator known as AutoRest.
Unifying the App Service developer experience in Visual Studio
With so many features in App Service being shared by each resource type – Mobile’s identity features more broadly-available asset, as well as the API Definition feature becoming available everywhere, and so on – we decided that the App Service developer experience needed to model itself in the same vein. One web application may make use of numerous REST APIs housed in the same resource group, only later to be further complemented with a mobile application. Given the evidence that there will always be something new in App Service, we’re unifying the publishing experience and providing a much simpler view of publishing your Web, Mobile, and API apps to App Service.
A redesigned, informative, and functional UI with more options
Along with this unification we’ve made some amazing strides in the overall look and feel of the App Service tooling experience. We’re excited to show off these new UI improvements, as they are the first wave of a huge re-engineering effort we’ve made in the App Service tooling team. We concentrated this first wave of redesign on taking some new steps in the design to emulate new Visual Studio UI concepts like Connected Services and the new Office tools. Underneath the new UI is a ton of code improvements, tweaks to make new service light-ups more efficient partner and customer-driven. You’ll hear more about the new extensibility the Azure Tools will offer in future posts, but for now let’s take a look at the new-and-improved design of the app selection and creation experiences.
Mitigating the “Which app do I want?” confusion
One consistent piece of feedback we received from customers and colleagues who publish many apps to Azure was that the list became unmanageable and that it was increasingly difficult to “guess” or to know which app should be the destination. We’ve borrowed from the Cloud Explorer design concept of providing both resource group and resource type views, we’ve made it easier to group your apps in the “Select Existing” dialog.
If regrouping isn’t enough due to the large number of potential publishing targets in your subscription, we’ve added one great feature – search. Now, you can free type your search query in the dialog and we’ll filter out the apps matching your term. The search is sticky, too, so if you search and then change your view between resource groups and types, the search will maintain and only the matches will be visible. Now it’ll be easier to find your publishing target from your subscription’s resource listing.
New App Service creation updates
Perhaps the largest steps we’ve taken to optimize to the App Service creation experience is in the app creation/provisioning process. The new dialog, shown below, offer numerous visual cues to the opportunities available during app creation. We’ve kept all the important hosting features on the first tab of a 2-tab experience. If all you need is a new app in the cloud and you’ve already got a resource group and hosting plan you’re interested in using for your new app, the process is as simple as clicking Create in the dialog new App Service creation dialog.
If you’re in need of a new App Service Plan, the creation of a new one is one click of the New button away. Once on the App Service Plan screen you’ll have the opportunity to create a plan from any of the possible sizes available in the portal.
If you want to create a new Resource Group into which your app will be published, simply type it into the Resource Groups combo box. When you do, the dialog will provide you with numerous visual cues to let you know you’ll be creating a new Resource Group (the blue icon indicator on the Hosting tab reflects the same message).
Creating additional services your app might need
The second tab of the new App Service creation screen provides you the opportunity to select any additional services your app might need. In this release, we’re maintaining our support for SQL Servers and databases in the App Service creation process. Now, however, you’re not limited to a single database. You can create as many SQL servers or databases as you need, directly within the dialog.
Though SQL is the only provider being released during the 2.8.1 SDK time frame, we’ve done some major engineering work to enable this dialog, part of which was to create an extensible model in which partner teams could work to extend their service light-ups. We’ve prototyped an experience of lighting up Redis provisioning in this same dialog, as well as some discussions with the Azure Key Vault and Document DB teams. In the not-so-distant future, you’ll be able to install extensions to this experience (and get the benefit of frequent or opt-in updates from the Visual Studio Extension Gallery integration in Visual Studio).
Export your Azure topology so it can be used to create mirror environments
As you move through the App Service creation dialog, configuring and adding services, each resource you add is shown in the initial Hosting tab’s review area. This “resource cart” provides a snapshot of all the resources you’re about to create in your subscription.
As you grow the number of resources you’ve added to your cart, the Azure Resource Manager JSON template is dynamically created an appended in memory. Once you’re sure you’ve added all the resources your app needs to function to your cart, a simple click of the Export button will prompt you for the location where you’d like to save the JSON template representing everything in your cart. Then you can either use the Azure PowerShell modules to execute your template into another resource group, or even into another Azure subscription. This feature enables customers with reproducible templates representing their application topologies, without the need to manually edit and configure the templates by hand. In the case that you need to customize the topology further, the built-in resource manager template editor features previously released integrate nicely, since the template-editing features recognize the JSON schema in the exported JSON file.
App Service project template updates
To accommodate new changes in the Mobile and API resources we’ve updated the Visual Studio templates to take advantage of new enhancements in the feature areas.
Mobile App template improvements
App Service Mobile makes it easy to build mobile applications which work with data offline, authenticate users, and send push notifications. We just announced general availability support for the Mobile Apps .NET server SDK, which allows you to build an application in App Service that serves these features, as well as custom logic, to your mobile clients. In conjunction with this release, we are today updating support for creating and managing a mobile app project in Visual Studio. To get started, open the New Project dialog from File > New > Project… Then expand Templates > Visual C#, and select "Web". Choose "ASP.NET Web Application," fill in the project name, and click OK. Under "ASP.NET 4.5.2 Templates," select "Azure Mobile App."
Click OK. Your application will be created and appear in the Solution Explorer. The template should feel familiar to customers using Mobile Apps or Mobile Services. The main difference that you may notice is in the configuration. The template now configures everything in OWIN Startup and gives you more granular control over what components are and aren’t added.
The project represents a simple to-do list application. Mobile clients can consume data stored in SQL through the TodoItemController, which derives from TableController. TableController translates mobile-friendly APIs into CRUD operations which can be understood by the data backend of your choice (in this case, SQL). It also adheres to the offline contract, so you can instantly start leveraging the Mobile Apps offline sync capabilities. You can add more table controllers or mobile-friendly API controllers by right-clicking on the "Controllers" folder and selecting Add > Controller. Then pick Azure Mobile Apps Table Controller or Azure Mobile Apps Custom Controller and follow the wizard to create your endpoint.
When you have your project ready, you can publish it to App Service using the new Publish dialog as described earlier in the article. Mobile Apps are now supported as a top-level publish target in the menu of options in the App Service creation dialog.
API App template improvements
The API App model evolved since its early preview. Since then, we’ve heard from customers that local debugging was important, so it is now enabled in the new API Apps template. This template results in a simpler overall structure, with fewer dependencies on resource management templates or API App Gateway-specific files. At its heart, the API Apps template is basically a Web API template, with the addition of the open-source Swagger-enabling NuGet package known as Swashbuckle. We’ve also included the previous SwaggerConfig.cs file changes we made so that the Swagger UI is disabled by default and included the operation filter that improved our approach to Swagger operation ID generation (read more about the Swashbuckle customizations on Azure.com).
REST API generation improvements
Mirroring the investment taken by App Service teams like API Apps and API Management with their use of Swagger, we’re continuing our investment with code-generation based on Swagger metadata exposed by API Apps. By clicking most C# projects in Visual Studio and selecting the Add > REST API Client gesture, the simplified REST API Client generator dialog will appear. Clicking the Browse button will take you to the “Select App Service” dialog, where you can select any App Service that has an API Definition endpoint set.
If you don’t already have an Azure account, you can sign-up for a free trial and start using all of the above features today. Then visit the Azure Developer Center to learn more about how to build apps with it. Please submit bugs through Connect, suggestions through UserVoice, and quick thoughts or ideas through Send-a-smile in the Visual Studio IDE. This release is an early step in a new direction for App Service tools, so we’re eager to hear your feedback, learn which services you’d like to see light up in the resource cart, and help us provide a more streamlined app development by continuing to give your input.
This blog post is a collaboration of multiple people. Big thanks to Matthew Henderson and all the teammates who worked hard on this release.