• Summary
• Technologies discussed
• Key Concepts
• Requirements and Constraints
• Existing Infrastructure
• How it works
• For Production
• Wrapping up

Summary

Desired Results

Technologies discussed

• Jenkins + Build Automation
• Powershell
• Azure Service Principal
• Azure Storage SAS Tokens
• Azure Resource Manager Template
• Azure Custom Script Extension

Key Concepts

• Build Automation
• Configuration Management
• Immutable Infrastructure

Requirements and Constraints

• MSI - The Web API build outputs an MSI file and that is what we need to get deployed to Azure. Ideally you'd be able to use git or WebDeploy or other cloud ready technologies for deploying to Azure. This example shows how you can automate deploying to Azure even when you have a constraint like MSI.
• VMs - The solution cannot use Platform-as-as-Service, it must be run on Windows VMs.
• Build Automation - the Web API must be deployed with automation, as part of a new or existing build automation process.
• Jenkins - The prescribed build automation tool.
• .NET 4.6.1 - The Web API needs to run on this version of the .NET framework.
• Non-standard Port - The Web API must use a non-standard http port, so not 80 and 443. This is sometimes a requirement in dev/test when resources are shared.
• No Custom Images - The VM must use the latest, patched version of Windows from the Azure catalog. Crafting a custom image with pre-loaded dependencies is not an option.

Existing Infrastructure

• Azure Subscription
• Jenkins instance installed and configured
• Azure Storage account that can hold build artifacts

How it works

Jenkins

$cmd = "C:\path\to\deploy.ps1"
$arg = @()
$arg += ("-buildNumber", $ENV:BUILD_NUMBER)
$arg += ("-CertificateThumbprint", "YOURCERTTHUMBPRINT")
$arg += ("-ApplicationId", "YOUR-APP-ID-GUID")
$arg += ("-TenantId", "YOUR-AAD-TENANT-GUID")
$arg += ("-sourceFile", "'C:\path\to\PasswordBot API.msi'")
$arg += ("-templateFilePath", "C:\path\to\template.json")
$arg += ("-subscriptionId", "YOUR-SUBSCRIPTION-ID-GUID")
$arg += ("-resourceGroupName", "resourcegroupname")
$arg += ("-resourceGroupLocation", "eastus")
$arg += ("-storageAccountKey", "YOURSTORAGEACCOUNTKEY")
$arg += ("-storageAccountName", "yourstorageaccount")
$arg += ("-artifactContainerName", "artifacts")
$arg += ("-configurationScriptFile", "C:\path\to\ConfigurationScript.ps1")
iex  "$cmd $arg" -Verbose

• buildNumber: Use Jenkins' environment variable so that each deployment # is incremented (this will also be used to label the Azure resources).
• CertificateThumbprint: You will need to create a service principal so that Azure resources can be deployed with automation. Please see this documentation for creating a service principal with a certificate in Azure. You will need to be an administrator of the Azure subscription and a global admin of the default Azure Active Directory tenant for that subscription. A certificate is generated when you create a service principal. The certificate needs to be stored on the build server and in the Azure AD application. Make sure you create the service principal with owner permissions. You can share the certificate with other build serves or dev machines. You will need to generate a private key to do this. Be careful where you store the certificate and the private key. Anyone who has this combination has "owner" rights to your Azure subscription! You can always delete the Azure AD application service principal if your credentials become compromised.
• ApplicationId: The GUID ID for the Azure AD Application associated with your service principal.
• TenantId: The GUID ID for the Azure AD Tenant associated with your service principal.
• sourceFile: The path to the MSI file you want to deploy. A sample MSI is provided in the Devops folder from the Github sample. This MSI file will install the PasswordBot Web API application, it will also create a new Website in IIS on port 81.
• templateFilePath: The path to the JSON template that defines the Azure resources we are going to deploy. This is also in the Devops folder in the Github sample.
• subscriptionId: The GUID ID for your Azure Subscription.
• resourceGroupName: The resource group that all the Azure resources will deployed within. You can choose any name you want within the guidelines.
• resourceGroupLocation: The Azure region that your resources are deployed to.
• storageAccountKey: A limitation of this example requires a pre-existing standard Azure storage account. Put the storage account key here.
• storageAccountName: the name of the pre-existing storage account.
• artifactContainerName: The name of the container in the pre-existing storage account where the build artifacts will be stored and accessed from the deploy script and eventually the VM.
• configurationScriptFile: The path to the file that will configure the VM and install the MSI. This can be found in the Devops folder in the Github sample.

Deploy File - deploy.ps1

• Line 31: Add-AzureRmAccount. This logs you into the Azure subscription for the Powershell session with the service principal credentials.
• Line 55: This uploads the Configuration file to Azure storage
• Line 65: We get a URL to the Configuration file that has a SAS token, which gives temporary (2 hour) permissions to read this file. We will pass this into the template so that once the Azure VM is provisioned, it can run this Configuration script.
• Line 72:  This time we are uploading the MSI File to Azure storage.
• Line 79: Now we get the URL to the MSI file with the SAS token. This is the MSI the configuration file will install on the VM.
• Line 84: We define the parameters for the Azure Resource Manager template. These could also be pushed back up into the parameters for the deploy file itself if we wanted to be able to control these items at the Jenkins level. You'll notice that we use the buildNumber and the Resource Group Name to dynamically name the different Azure resources we are creating.
• Line 106: We are looking to see if a Resource Group with the same name already exists. If it doesn't, we create it.
• Line 123: This is where the magic happens. We deploy our Azure Resource Manager template with the parameters we defined at line 84.  See the Template File section below to understand what happens inside the template file.
• Line 126: Our configuration requires the Windows VM to restart.

Template File - template.json

• parameters
• resources

• availabilitySets: Defines the availability set that the Azure VMs will live in. VMs in an availability set are deployed in separate fault and upgrade domains so that they aren't all taken down at the same time due to scheduled maintenace or unscheduled outages. If you've ever heard of splitting up travel executives on separate planes, it's the same idea.
• virtualMachines: The attributes for the Azure VM we are creating. Notice a couple of important things:
  • dependsOn. Before the VM can be created, it has dependencies on other resources. It needs the availability set that it will be placed in, it needs the storage account that will hold it's virtual disk(s), and it needs the NIC card that it will use to connect to networks. The Azure Resource Manager uses these dependencies to figure out what resources to build first and, if possible, which resources can be built in parallel.
  • resources. The VM resource has its own resources section. In this case we are defining a Custom Script Extension. The custom script extension pulls down the Configuration script and the MSI file onto the provisioned VM and executes the configuration script.
  • imageReference. You can see we are deploying the latest patched version of Windows Server 2012 R2. This is important to understand for configuration management. We are not building custom images with our app baked in. We are building plain vanilla Windows VMs and automating all the configuration of the VMs including installing our app on it.
  • Count. We are only deploying 1 VM here. If we choose to, it is simple to deploy many VMs at the same time with this template.
• networkInterfaces: The NIC card for our VM
• networkSecurityGroups: The Network Security Group that defines what traffic is permitted through to subnet where the VM is located.
• publicIPAddresses. We create a public IP address so the VM is available over the internet.  Notice dnsSettings/domainNameLabel, we can use that to reach our VM with a domain name.
• virtualNetworks: We create an Azure Virtual Network with a subnet that will host our VM.

Configuration Script File - ConfigurationScript.ps1

• Line 1, takes the MSI file as a parameter. When the Custom Script Extension calls this configuration script it passes in the MSI as parameter. Both the ConfigurationScript.ps1 and MSI are downloaded to the VM by the template after it provisions the VM.
• Line 15, installs IIS - we need this to serve the Web API inside of the MSI.
• Line 27, our API is 32 bit, but the Windows Server is 64 bit. So we need to set this so that IIS can serve our API.
• Line 32, we open port 81 for bot API - the MSI will install a new Website in IIS on port 81.
• Line 36, we install the MSI file.
• Line 42, the required .NET Framework is downloaded and installed.

Build

For Production

• The ARM template can be updated to publish multiple VMs or to VM Scale Sets.
• A load balancer can be added to send requests to all VMs
• The VM(s) can be further locked down by shutting down unneeded ports.
• Add server diagnostics for the VMs for monitoring in production.
• An NSG rule is created for RDPing into the VMs. This can be removed when immutable infrastructure is used in production.
• Use a Windows Server Core Image for faster/lighter weight deployment.
• If your app is I/O intensive, use a VM with disks hosted on Azure Premium Storage.
• If your app is RAM intensive, use a VM size with more RAM.
• Re-deploy every month to get a patched Windows Environment.

Wrapping Up

• Introduction
• Resources
• Resource Groups vs Subscriptions
• Developing with VNets
• Governance
• Tools

Introduction

• How do I get organized in Azure?
• How can I see what's happening with Azure services in my subscription?
• How do I manage my spend with Azure?
• How can I control access to resources inside of Azure?
• How can I make sure my apps are being developed securely in the cloud?

Resources

Recommendation: If you're just starting in Azure, don't create RBAC or Policies yet. Give everyone on the team a chance to explore Azure and get comfortable with deploying different resources. Give your developers a chance to discover native Azure solutions to help them meet their needs. Once a cloud architecture for your apps has been decided upon, then it makes sense to start locking down the dev environment in preparation for production.

Resource Groups vs Subscriptions

Recommendation: If everyone is new to Azure, start off by giving every team their own Azure subscription so nobody is stepping on anybody else's toes. If teams need to work together, they will eventually self-organize and choose a primary subscription to work in.

Developing with VNets

• Who owns the VNet?
• What port are allowed on the VNet?
• What subnets can talk to what subnets?
• What VMs can reach the Internet?
• What VMs can be reached by the Internet?
• Can I connect my VNet to another VNet?

Governance

Tools

1. Setup
2. Create Cloud Service Files
3. Create Web Role
4. Copy Existing App
5. Deploy Cloud Service

Do you have an existing ASP.NET website that you'd like to deploy on Azure and get the benefits of Azure's Platform as a Service capabilities? The easiest and quickest option is to use Azure Web Apps. Azure Web Apps gives you create flexibility but it does not allow you to customize the underlying operating system that much. For instance, if your existing ASP.NET website has a dependency on applications being installed into the web server, Web Apps may not be the best option. In this case you have a few options:

1. Rewrite the application to not require the dependency on installed applications.
2. Use Infrastructure as a Service (IaaS) to deploy a Windows IIS Web Server.
3. Use Azure Cloud Services with Startup Tasks to install the required applications.

Rewriting the application is often not a choice and using IaaS means you do not get the benefits of PaaS. This article is about using Cloud Services. Cloud Services is one of the earliest services on the Azure platform. There is already a ton of great content out there on Cloud Services. However, there is not much content about porting your existing ASP.NET app to Cloud Services, so I am going to lay out some simple steps.

SETUP

For this walk-through, I have a simple ASP.NET website targeting .NET 4.0. I want to deploy it on Azure with a custom startup task that will run when the Cloud Service instance(s) are deployed. 

CREATE CLOUD SERVICE FILES

Make sure you have Azure Powershell installed. Choose a directory to work in.

Run Powershell as administrator.

Execute

PS C:\projects\CloudServices> New-AzureServiceProject -ServiceName ExistingAppDemo

This will create a folder with the Service Name and move into that folder:

PS C:\projects\CloudServices\ExistingAppDemo>

Inside you will find the following metadata files that Azure needs to create a cloud service:

• deploymentSettings.json - required by PowerShell for deploying Cloud Services
• ServiceConfiguration.Cloud.cscfg - this is the cloud service configuration file Azure will use. We won't touch this file for this walkthrough.
• ServiceConfiguration.Local.cscfg - this is the cloud service configuration file that your local emulator will use. We won't touch this file for this walkthrough.
• ServiceDefinition.csdef - this is the service definition file. We will be making changes to this file.

Now that you have these metadata files, you need to run your website inside of a Web Role.

CREATE WEB ROLE

To create a web role, remain in your current directory and type:

PS C:\projects\CloudServices\ExistingAppDemo> Add-AzureWebRole

This does a few of things:

• It updates your Service Configuration files. It adds a Role element with some configuration. We will leave the defaults.
• It updates your Service Definition file. It adds a WebRole element and includes some child elements including Startup tasks. 

We're going to edit the ServiceDefinition.csdef file:

Change the vmsize attribute on the WebRole element to "ExtraLarge" - the default ExtraSmall VM size takes a while to spin up and configure so to get going faster we'll use ExtraLarge. This can always be changed later when you're ready to deploy your site for production use.

There are 2 Startup tasks. Remove the first task (the one that calls "setup_web.cmd"). It's not necessary for this walkthrough. So, completely remove this block of code:

 <Task commandLine="setup_web.cmd &gt; log.txt" executionContext="elevated">
 <Environment>
 <Variable name="EMULATED">
 <RoleInstanceValue xpath="/RoleEnvironment/Deployment/@emulated" />
 </Variable>
 <Variable name="RUNTIMEID" value="" />
 <Variable name="RUNTIMEURL" value="" />
 </Environment>
 </Task>

That's it.

Adding the WebRole also creates a new directory called WebRole1. Inside WebRole1 are a few items. You are going to delete most of them:

Delete the bin folder

Delete the Web.cloud.config file

Delete the Web.cloud.config file

KEEP the startup.cmd file. Notice that in your Service Defintion file, there is a task that calls startup.cmd:

 <Startup>
 <Task commandLine="..\startup.cmd &gt; startup_log.txt" executionContext="elevated" />
 </Startup>

That is the same startup.cmd file that is in this folder. This where you can put in your own custom startup tasks (silent installs of your required installed apps). If your start up tasks require executables or MSIs, you can include them in the bin folder and reference them in the startup.cmd file. Does your Existing ASP.NET require a version of .NET newer than 4.0? You can install a newer version of the .NET framework as a startup task! See https://azure.microsoft.com/en-us/documentation/articles/cloud-services-dotnet-install-dotnet/. This is a great example of how to use startup tasks.

COPY EXISTING WEB APPLICATION

Find the files for your existing ASP.NET application. 

Here's my test app:

Here's the magic: We are going to move (or copy and paste) the TestApp into the WebRole1 directory we just created in C:\projects\CloudServices\ExistingAppDemo\WebRole1. The end result should look like this:

It should look EXACTLY the same except for the remaining startup.cmd.

Almost done!

DEPLOY CLOUD SERVICE 

You've got your Cloud Service ready. You've got a WebRole defined and populated with your existing ASP.NET website's code.

Go back up to the Cloud Service directory:

PS C:\projects\CloudServices\ExistingAppDemo> 

and type:

PS C:\projects\CloudServices\ExistingAppDemo> Publish-AzureServiceProject -ServiceName ExistingAppDemo

This will package up your cloud service and deploy it a service named "ExistingAppDemo."  If you've chosen a service name that already exists, you'll get an error - just run the command name with a different service name. 

It will take a few minutes to deploy your app, you should see the following messages:

WARNING: Publishing ExistingAppDemo to Microsoft Azure. This may take several minutes...
WARNING: 2:05:13 PM - Preparing runtime deployment for service 'ExistingAppDemo'
WARNING: 2:05:13 PM - Verifying storage account 'existingappdemo'...
WARNING: 2:05:46 PM - Preparing deployment for ExistingAppDemo with Subscription ID: b59a9b75-a297-41fc-8773-4f3713391c19...
WARNING: 2:05:55 PM - Connecting...
WARNING: 2:05:56 PM - Creating...
WARNING: 2:05:59 PM - Created hosted service 'ExistingAppDemo'.
WARNING: 2:05:59 PM - Uploading Package to storage service existingappdemo...
WARNING: 2:06:01 PM - Starting...

Everything should have been successful and you'll see the unique URL for your new web app in an Azure cloud service! Your cloud service is available in the Azure portal:

Obviously this is just the beginning. You'll need to manage the Cloud Service, scale it, secure it, add your custom domain, etc. 

With your cloud service, you've now got your existing ASP.NET webapp in Azure, utilizing Azure's Platform as a Service even though your app has installed dependencies!

More information:

• Azure Cloud Services: https://azure.microsoft.com/en-us/documentation/services/cloud-services/
• Silent /Unattended Installs: https://unattended.sourceforge.net/installers.php

This pertains to Umbraco 4.5.

1. First edit this file in the config folder: tinyMceConfig.config. Add a new set of elements to //commands:

    <command>
      <umbracoAlias>mceTest</umbracoAlias>
      <icon>images/editor/mceTest.gif</icon>
      <tinyMceCommand value="mceTest" userInterface="false" frontendCommand="mceTest">mceTest</tinyMceCommand>
      <priority>3</priority>
    </command>

Make sure the values for mceTest all match. You can insert your own image or choose an existing image for icon.

Add to the plugins node:    

<plugin loadOnFrontend="false">mceTest</plugin>

Save the file.

2. Create a new folder in \umbraco_client\tinymce3\plugins with the name of your plugin (mceTest in this case).

Inside this folder you need at least 2 files: editor_plugin.js and editor_plugin_src.js. The editor_plugin.js file is the same as the editor_plugin_src.js just compressed. When you are working in debug in your dev environment make sure your changes to editor_plugin_src.js. When you are ready to deploy your plugin, crunch the code and put it in editor_plugin.js.

3. Create editor_plugin_src.js and add the following scaffolding code:

(function () {

    tinymce.create('tinymce.plugins.mceTest', {

        init: function (ed, url) {


           var t = this;

            t.editor = ed;



            // Register buttons

            ed.addButton(

         'mceTest', {

             title: 'Create collapsible area',

             image: url + '/images/icon.gif',

             cmd: 'testButton'

         });

        },



        createControl: function (n, cm) { return null; },



        getInfo: function () {

            return {

                longname: 'mceTest',

                author: 'mceTest',

                authorurl: 'mceTest',

                infourl: 'mceTest',

                version: tinymce.majorVersion + "." + tinymce.minorVersion

            };

        }

    });


    // Register plugin

    tinymce.PluginManager.add('mceTest', tinymce.plugins.mceTest);

})();

Make sure you replace mceTest with the name of your plugin everywhere in this file. If you are publishing this plugin you can change the longname authorurl and infourl values.

There is plenty of documentation on how to create behavior in this file, and you can look at the other plugin folders to see simple and complicated examples. You can even add html files to create forms when users click your button in the tinymce toolbar.

4. For this example, I am going to be adding a simple Jquery-based expand/collapse widget to the tinymce toolbar, the only code necessary for this example is the following lines added just under t.editor = ed;

        init: function (ed, url) {



            var t = this;

            t.editor = ed;

            ed.addCommand('testButton', function (ui, v) {

                ed.execCommand('mceInsertContent', false, '<p></p><div class="ExpColCon"><div class="ExpColTitle">Title Goes here</div><div class="ExpColBod"><p>Body<br/>Goes</br/>Here</p></div><p></p>');

            });



            // Register buttons

            ed.addButton(

         'mceTest', {

             title: 'Create collapsible area',

             image: url + '/images/icon.gif',

             cmd: 'testButton'

         });

        },

What will this code do? It will insert into the editor some html markup with styles for expand/collapse (I'll show you the Jquery to make this work on the actual templated web page below). It will be easy for the end-user to update these fields with their own text/html.

5. To make sure the end-user can understand what they are seeing, edit the css for the editor form which is located in \umbraco_client\tinymce3\themes\umbraco\skins\umbraco\content.css

.ExpColCon

{

	padding:7px;border:1px dotted #333333

}



.ExpColTitle

{

		padding:3px 3px 3px 20px;border:1px dotted blue; color:blue;

		font-family:Verdana,Arial,Helvetica,sans-serif;

		font-size:80%;

		font-weight:bold;

		background-image:url('/umbraco/images/Lplus.png');

		background-position:0px 3px;

		background-repeat:no-repeat;

}



.ExpColBod

{

		padding:3px 3px 3px 20px;border:1px dotted red; color:#666666;

}

Now when you click the button to add the expand/collapse region, you will see it outlined in the editor. NOTE that this CSS is NOT The CSS  on the resulting public facing template. You can define other styles there. This CSS is just helpful for the end user writing content in the tinymce editor.

So if you've done all this, then go to your Umbraco CMS authoring environment. You may need to dump your cache as Javascript and CSS files get cached and your state may not be correct.

6. Create a new Datatype using the tiny MC3v3 wysiwyg Render Control. You should see your new button as one of the choices. Make sure you check that button and save your new DataType.

7. Save your DataType. Create a new DocumentType and add a new property based on your new DataType.

In your content when you create a new Document based on your DocumentType, you should see the tinymce editor show up with your new button!

When you click the button, some markup will be added to your editor surface. Because we added the css to the editor's content.css file, the expand/collapse fields are easily marked:

Now it's easy for an end user to update the title and the body of the expand collapse field.  To use this code in your template just add this simple Jquery:

    <script src="https://ajax.aspnetcdn.com/ajax/jquery/jquery-1.4.4.js" type="text/javascript"></script>

    <script type="text/javascript">

        var expcolconstyle = ".ExpColCon";

        var expcoltitlebodycontainer = "div";

        var expcolconselector = expcolconstyle + " " + expcoltitlebodycontainer + ":nth-child(#)";

        var expcoltitleselector = expcolconselector.replace("#", "1");

        var expcolbodyselector = expcolconselector.replace("#", "2");

        $(document).ready(function () {

            $(expcolbodyselector).hide();

            $(expcoltitleselector).attr("style", "cursor:pointer");

            $(expcoltitleselector).click(this, function () {

                var expcolbody = $(this).parent().children(expcolbodyselector);

                expcolbody.toggle();

                //alert(expcolbody.text());

            });

        });

    </script>

You'll notice only the wrapping DIV.ExpColCon is important. The first child (regardless of style) will be treated as the Title and the the second child will be treated as the body. This gives you freedom to change these styles in the future.

Thanks,

Mike

Now I am working in ASP.NET MVC where, if done correctly, there are some serious separations of concerns. Now, my widgetA ViewModel is in the "ViewModel" folder tree, the associated View.ascx file is the "Views" folder, javascript, css and images all in separate folders under a "Content" folder.

When I am working on the widgetA feature, it's a little annoying to have to walk through the whole tree to find everything I need. I considered creating a solution folder called widgetA and then adding all related files to that solution folder. That seemed too hard to maintain and would take a long time to get to widgetZ.

 Enter the Solution Navigator, part of the latest Productivity Power Tools Update extension for Visual Studio. It has a great Filter feature which allows you to filter your entire solution based on a string. If you follow the MVC "convention over configuration" paradigm and name all your related files similarly, the Filter will find them for you no matter where they are in your solution. Note this works across all the projects in your solution.

The Solution Navigator makes working on a big MVC project much simpler for me and I am now able to group files by function rather than feature.

Let me know what you think; maybe there are better ways to organize files or structure a solution. I tried to to look for ways to automate creating Solution Folders for this specific scenario, but the effort didn't seem worth it. Has anyone come up with something easier?