Tech Blog

Azure Enterprise Integration Series – Part 3

Azure Enterprise Integration Series

Part 3: Visual Studio and Project

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

1. Visual Studio Development

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
environments, etc.

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.

2. Project Types

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

API Connection

App Service

Azure SQL Server1

Integration Account2

Logic Apps3

Service Bus

Storage Account


Azure Functions


ASP.NET Web Application

Web App4

Mobile App4

API App4


Integration Account contents (schemas etc.) 3

Web Job

Web Job

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
 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
 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.

2.1 ASP.NET Web Application Project

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
testing framework, we suggest you select the option to
unit tests
 in the above dialog – this will create a
separate Unit Tests project with an example of a unit test.

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
Publish option):

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
an App Service/App Service Plan for this app (via the Publish option), we recommend
creating a separate
Azure Resource Group project
in Visual Studio that contains an
App Service and App
Service Plan
 for this ASP.NET
Web Application
 project. This Resource Group Project
can then be deployed from both Visual Studio and VSTS.

Note: One thing that the above dialog is
useful for, is creating an ARM Template that specifies your App Service and App Service
Plan: if you fill in the dialogue, and then click the
Export… button,
it will save an ARM Template file that you can use in an
Resource Group
 project, and you can then cancel out
of the dialog.

2.2 API App Project

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 App Service/App Service Plan for this app (via the Publish option), we recommend
creating a separate
Azure Resource Group project
in Visual Studio that contains an
App Service and App
Service Plan
 for this ASP.NET
Web Application
 project. This Resource Group Project
can then be deployed from both Visual Studio and VSTS.

2.3 Azure Functions Project

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 portal, but this is not recommended as any changes are not automatically reflected
in Source Control in VSTS.

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:

File Name





Contain settings for the function e.g. type of trigger, type
of output, whether it starts disabled etc. For Logic App functions, you shouldn’t
need to edit this, if a Generic WebHook template was used.



Contains a list of dependencies this function needs from NuGet
(or locally).



Contains the source code for the function.



Contains sample data that works with the sample code in run.csx.


Function App

Contains settings that affect the Function
 App Service.


Function App

Contains information about the host used with the App Service.


Function App

Read Me file, is displayed by Visual Studio when an Azure
 project is first created.

Note: support is being added to functions
for ability to use code from a pre-compiled assembly; and additionally, to have a
parent function that can look at a request and forward it to a child function (function
proxy). Neither of these features are available in Visual Studio now, but moving forward
it will make sense to have a separate C# Library project that contains classes with
the function code in them: this will allow for easier unit testing and editing.

Note: Although an Azure Functions project
has a Publish option, the Function App it deploys is broken, and not visible from
Logic Apps. For this reason, we recommend creating a separate
Resource Group
 project in Visual Studio that contains
App Service and App
Service Plan
 for the Function App.

The default run.csx file
for a C# Generic Webhook project looks like this:

2.4 Azure Resource Group Project

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
visual studio extension can be found at the end of this article.

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:

File Name




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
is created, the idea is to create multiple template files, one for each environment.


A Deployment PowerShell script

Contains a default script that creates the Resource Group and then
deploys the ARM Template. This is the script that Visual Studio executes when you
select the
Deploy option
for the project. Changing the name of this file will break the ability to deploy this
project from Visual Studio.

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
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.

2.5 Integration Account Project

An Integration Account project type
is used to create and store XSD Schemas and Transforms used with Azure

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:

Item Name


Flat File Schema

Opens the BizTalk Flat File Parser wizard,
allowing you to build a flat-file schema (for use with the Flat File Parsing connectors
in Logic Apps) from a sample flat file (e.g. csv or positional file).

XML Schema

Opens the BizTalk Schema Editor, which allows you to create/edit
an XSD file.


Opens the BizTalk Mapper, which allows you to create or edit
a BTM map file.

There are a couple of restrictions with this project type:

  • You can’t install the Integration Account type on the same PC that
    has BizTalk Server installed – they use the same components and don’t currently play
    nice with each other
  • Only Visual Studio 2015 is supported (at this time)
  • The BTM files generated by the mapper are converted into XSLT files
    (stored in the bin folder) when the project is built
  • You can’t put maps in folders: they need to stay in the root folder
  • There is no option to create an Integration
     nor publish the schemas/maps to an existing Integration
     from this project

Note: The link to download the Integration
Account project extension can be found at the end of this article.

Note: We recommend that you create a separate Azure
Resource Group
 project that will create the Integration
Account in Azure and deploy the schemas/maps from this project. The script for this
will be covered in the next article/video.

3. Further Reading

How to author an ARM template:

ARM Template expression and functions:

Integration Account visual studio extension

Logic Apps Visual Studio extension

Back to Tech Blog