This is the third in a series of 12 blog posts on Azure Enterprise
Each blog post is accompanied by a video that covers the same
As an enterprise integration developer, Azure gives you some new
choices. Foremost amongst those is the ability to develop code *outside of Visual
Studio*. Whilst that is the norm for most open-source and non-Microsoft technologies
(e.g. Python, Ruby, anything developed on a non-Windows PC), for most Microsoft integration
developers, developing outside of Visual Studio may take you outside of your comfort
In fact, when Logic Apps first debuted, much was made of the fact
that you could develop in your browser – a revolutionary idea (to Microsoft developers)
and one that Microsoft have put a lot of time and effort into.
In fact, the early versions of Visual Studio Online were focused
around you being able to write. Test, and deploy C# code from your browser, the legacy
of which still carries on with Azure Functions today.
But developing in a browser introduces its own concerns: how you
do manage your code, how do you source control it, what about promoting it to different
Some organisations love the idea of browser development: these are
organisations that have jumped whole-heartedly on the Agile bandwagon, use Git and
Scrum, release regularly, and much prefer a lighter-weight development process.
But for most Enterprises, Visual Studio is where it’s at: it complements
our existing development processes; reduces training on new development techniques;
and is familiar to most of the developers we employ.
Although Visual Studio contains templates for many different types
of projects, we’re only interested in a subset of them for Azure integration development:
Visual Studio Project Type
Supported Azure Resources
Azure Resource Group
Azure SQL Server1
ASP.NET Web Application
Integration Account contents (schemas etc.) 3
SQL Server Database
Database objects (tables etc.) 2
There are a few discrepancies with the project types though:
1 An Azure SQL Server is
defined in an ARM template, although the SQL entities (databases, tables, stored procedures,
etc.) need to be defined in a separate SQL Server Database project.
2 At the current time, the Integration project
type doesn’t support the creation of the actual Integration
Account in Azure, so you need a separate Azure
Resource Group project that contains the ARM Template
for the Integration Account.
3 Although Logic Apps are created in an Azure
Resource Group project, they have their own designer.
They are the only resource in an Azure Resource Group project that has a dedicated
4 The ASP.Net Web Application project
type contains the code for web applications, but doesn’t define the App
Service or App Service Plan (ASP):
you need a separate ARM Template for this. Although you can create the App Service/ASP
at the time you publish from Visual Studio, this doesn’t allow you put the definition
for the App Service/ASP in source control.
Most of the project types we use for integration development can
be found in the cloud category:
The rest of this section covers the individual project types.
The ASP.NET Web Application project
template covers most Azure App Service technologies (Web Apps, API Apps, Mobile Apps).
After selecting this option (and entering the project/solution name
details), you are given a dialog where you can select the type of ASP.NET technology,
and whether you want to host in in Azure:
Note: If you’re using the Visual Studio
The example in the image above shows that we wish to create an Azure
API App and to host it in Azure.
Selecting the Host in the cloud option
will cause a secondary dialog to appear, which is used to create an App Service and
create/select an App Service Plan (this is the same dialog used when you choose the
Remember: An App Service is equivalent
to an IIS Application, and the App Service Plan defines
the type of Server Farm your application is hosted on (i.e. how many servers, types
of servers, how much memory you have, etc.).
We recommend that you *don’t* select the option to host in Azure at project
creation: the rationale behind this is that you still must supply the same information
in an ARM template (i.e. the App Service and App Service Plan) to deploy the App Service
(and your ASP.NET application) from VSTS.
Note: Although Visual Studio can create
Note: One thing that the above dialog is
API Apps are a type of ASP.NET Web Application project,
and are created by selecting that option under Cloud projects. The API App template
is then selected:
The API App template in Visual Studio creates a stubbed MVC REST
app, with a Swagger interface:
The developer then modifies this stub to implement the required functionality:
the actual REST methods are contained in the ValuesController.cs file.
Note: Although Visual Studio can create
An Azure Functions project is a specialization
of an ASP.NET Web Application project: Functions
are hosted in a Function App, which is a specialized version of an App Service (technically,
Functions are a type of Web Job, which is a type of App Service). Function Apps also
use an App Service Plan: A Function App can use
a standard App Service Plan (which limits
the number of executions, but is charged at a regular monthly amount); or it can use
a dynamic App Service Plan (known as consumption billing),
where you pay per execution. The Azure Functions project
in Visual Studio represents the Function App that needs to exist in Azure.
Note: Functions can also be authored in
The Azure Functions project
template is (as of this writing) in preview – therefore its capabilities (and its
location) may change in future.
To create an Azure Functions project, select the template from the
New Project screen:
This will create a stub Function App project that looks like this:
An Azure Functions project
can contain one or more functions – each function will be in a separate folder in
the project. When the project is first created, it will contain no functions – functions
can be added by the “Add” option in the project:
The New Azure Function dialog allows
you to select the type of function to create:
A function will consist of several files, depending on the template
chosen. The example shown (and discussed) below is for a C# Generic Webhook function:
The function and function app files shown are:
Contain settings for the function e.g. type of trigger, type
Contains a list of dependencies this function needs from NuGet
Contains the source code for the function.
Contains sample data that works with the sample code in run.csx.
Contains settings that affect the Function
Contains information about the host used with the App Service.
Read Me file, is displayed by Visual Studio when an Azure
Note: support is being added to functions
Note: Although an Azure Functions project
The default run.csx file
for a C# Generic Webhook project looks like this:
The Azure Resource Group project type
lets you manage resources specified via ARM Templates.
When you create an Azure Resource Group project,
you can choose to start from a number of pre-populated ARM Templates (including QuickStart
templates from GitHub), or from a blank ARM Template:
Notice that Logic Apps are one of the items in the list – if you select this
option, you get a stub Logic App (i.e. something that the Logic App designer recognises
as a Logic App and which it can open). Note that this assumes you have installed the
Logic App tooling for Visual Studio.
Note: The link to download the Logic App
For some resources, e.g. Service Bus Namespaces, Storage Accounts,
API Connections, etc., there is no template: you must start with a blank ARM Template
file and add the content yourself.
No matter which template you select, you’ll end up with a project
with 3 files in it:
An ARM Template
A JSON file that describes what should be created.
An ARM Template parameters file
A JSON file which contains values passed in to the ARM template.
Note: although only one of these
A Deployment PowerShell script
Contains a default script that creates the Resource Group and then
When you right-click the project file and select Deploy, you’re given
the option of selecting an existing deployment, or creating a new one. All this does
is pre-populate the name of the ARM Template file to use, the Parameter file to use,
and the subscription being used:
Creating a new deployment prompts us to select the Subscription,
Resource Group, ARM Template, Parameters File, and also allows us to edit the parameter
When we kick off a deployment, all that happens is that Visual Studio executes
the Deploy-AzureResourceGroup.ps1 using
the values supplied above.
For this reason, it is important that you don’t edit the Deploy-AzureResourceGroup.ps1 file
unless you are extending the deployment in some fashion.
An Integration Account project type
is used to create and store XSD Schemas and Transforms used with Azure Integration
It is created via this option:
When the project is created, it has no resources in it.
Selecting the “Add New Item” gives 3 options:
The available items are:
Flat File Schema
Opens the BizTalk Flat File Parser wizard,
Opens the BizTalk Schema Editor, which allows you to create/edit
Opens the BizTalk Mapper, which allows you to create or edit
There are a couple of restrictions with this project type:
Note: The link to download the Integration
Note: We recommend that you create a separate Azure
How to author an ARM template:
ARM Template expression and functions:
Integration Account visual studio extension
Logic Apps Visual Studio extension