You no doubt have countless questions ;)

FAQ:

Where are you going?

I'll be heading over to work for Citrix (doing software development of course)

Where is your new blog?

Follow me on twitter, and on my user about page I'll have a link to my new blog once I get it out there: https://twitter.com/TrampSansTom

I got nothing but love for Microsoft, and I believe the feeling is mutual on their side too.

The open door / closed door problem was just something I was messing with after an interview question about it.

Wanting to verify that my original solution was actually correct (it was)

You can check it out here on typescript playground (which is a sweet playground):

http://www.typescriptlang.org/Playground/#src=%0Aclass%20Door%20%0A%7B%0A%20%20%20%20status%3A%20boolean%3B%09%0A%7D%0A%0Avar%20doors%20%3D%20new%20Array()%3B%0A%0Afor%20(var%20i%3D0%3B%20i%3C100%3B%20i%2B%2B)%0A%7B%0A%09var%20newDoor%20%3D%20new%20Door()%3B%0A%09newDoor.status%20%3D%20false%3B%0A%09doors.push(newDoor)%3B%09%0A%7D%0A%0Afor%20(var%20x%3D0%3B%20x%20%3C%20doors.length%3B%20x%2B%2B)%0A%7B%0A%09for%20(var%20y%3Dx%3B%20y%20%3C%20doors.length%3B%20y%20%3D%20y%20%2B%20x%20%2B%201)%0A%09%7B%0A%09%09if%20(doors%5By%5D.status%20%3D%3D%20false)%0A%09%09%7B%0A%09%09%09doors%5By%5D.status%20%3D%20true%3B%0A%09%09%7D%20%09%0A%09%09else%0A%09%09%7B%0A%09%09%09doors%5By%5D.status%20%3D%20false%3B%09%0A%09%09%7D%0A%09%7D%09%0A%7D%0A%0Afor%20(var%20z%20%3D%200%3B%20z%20%3C%20doors.length%3B%20z%2B%2B)%0A%7B%0A%09var%20listthing%20%3D%20document.createElement('li')%3B%0A%09listthing.textContent%20%3D%20doors%5Bz%5D.status%3B%0A%09document.body.appendChild(listthing)%3B%0A%7D%0A%0A

Open Door / Closed Door problem - given n number of doors:

1) Go through the list of doors, and "toggle" the state of every door

2) Go through the list of doors again, starting with the "next" door, toggle every other door

3) Go through the list of doors again, starting with the "next next" door, toggle every other other door 

4) And on and on

I wanted to see what I could find out there in regards to GitHub data.

There were a couple choices I had: use their open API (which allow for a limited set of use daily) or use Google's Big Query engine which happens to have a ton of GitHub data available in it's list of public data sets.

So I went with Google's Big Query engine. And it's pretty slick. Despite having a lot of intermittent failures when running queries or downloading data, I was able to successfully do some pretty cool querying.

I found some data in there (old data, from 2012) regarding language correlation. I knew I wanted to do something like that, but definitely needed something more recent than ancient 2012.

And thanks to Data Hacker MD's post on Language Use On GitHub I was able to get started.

The steps were pretty simple:

1) Get a free 60 day trial account on Google's Big Query

2) Filter out the data I wanted, and shove that into a new "table"

3) Export the table to a very large CSV file

4) Run Data Hacker MD's python script over the data (which uses Spearman's Rank Correlation to determine the correlation between any 2 languages)

5) Exports the results as a SVG file (Scalable Vector Graphics) that you can see below

What we have here is an answer to the question:

"If person A writes code in Language X, are they also likely to write code in Language Y?"

Or in other words:

"If someone writes a lot of Javascript, does that mean they also write a lot of CSS?" (Answer: chart below shows a slightly strong correlation not surprisingly)

Some interesting conclusions:

• There is a fairly strong positive correlation between PowerShell and TypeScript...very weird
• C# users aren't likely to avoid other languages (I don't see any negative correlations in the C# column...well except for Puppet)
• But Visual Basic Users, they area a bit more insular and seem to favor certain languages over others.
• Plus, very few languages had a strong negative correlation (XSLT and Julia...)

But overall, and maybe it's just me, but comparing my chart from 2014 - Feb 2015 to Data Hacker MD's chart, seem to show that software developers are developing across multiple languages more and more (i.e. less redish coloring)

You can check out the implementation in a nice typescript playground on typescript.org sandbox, or if you'd rather I have it below.

Later on I'll blog out the intricacies of animating the Medical School / Resident matching algorithm and things learned along the way (not expecting it to be the most popular thing I've ever written but maybe thousands of Med Schools residents will finally find that animated algorithm they've been dreaming of)

 Typescript implementation:

//A typescript implementation of a generic Collection
class Collection<T> {

    // The underlying array data structure of the collection
    private _items = [];

    // Get the collection as an array
    public GetItems() {
        return this._items;
    }

    // Get a specific item from a collection given it's index
    public GetItem(index: number): T{
        return this._items[index];
    }

    // Length of the collection
    public Count() { return this._items.length; }

    // Add an object to the collection
    public Add(item: T) {
        this._items.push(item);
    }

    // Delete an object from the collection
    public Delete(itemIndex: number) {
        this._items.splice(itemIndex, 1);
    }

    // Find the index of a given object in a collection
    public IndexOfItem(obj: T, fromIndex?: number) :number {
        if (fromIndex == null) {
            fromIndex = 0;
        } else if (fromIndex < 0) {
            fromIndex = Math.max(0, this._items.length + fromIndex);
        }
        for (var i = fromIndex, j = this._items.length; i < j; i++) {
            if (this._items[i] === obj)
                return i;
        }
        return -1;
    }
}

Update 09/23/2014: I "fixed" the "apiVersion" values in the below JSON so that they pointed to the recent versions. This will problem be a problem again in the future. One way to see what the latest apiVersion is is to simple look at the other parts of the website.JSON and see what version they use.

The Azure Resource Manager Tools (Preview) for Visual Studio have been available for almost a week now, so I think it's time to move beyond the basic scenario and do something more advanced.

• Note: Not familiar with Azure Resource Manager or the Tools yet? I'd recommend you check out this Azure Blog which gives a quick introduction to everything you need to get started here.

Using the tooling, we are going to walk through creating a Web Application, deploying our Azure resources (e.g. websites and databases), and publishing our application. We'll accomplish this by editing an Azure Gallery Template (maybe you've seen these already on the new Azure Portal) so that it not only deploys all the Azure resources we need, but also does the publishing part for us. We won't be publishing to Azure using a "Publish Wizard" in this tutorial. And we won't be using the Azure Portal website for creating any resource. We are going to do everything strictly from Visual Studio.

Before we can experience all of this, make sure you install the Azure RM Tools (Preview) for Visual Studio. Also, you'll need an Azure account. Don't have one? Then you can sign up for a trial one here.

Let's get started creating our web application, then we'll move onto deploying our Azure resources, and to top it off we'll publish the app. Again we'll be using nothing but the tooling we've made available in Visual Studio.

Create a Web Application

Let's get started creating the web application.

1. Launch Visual Studio
2. Go to File -> New Project -> Cloud -> Cloud App from the Azure Gallery
1. 
3. Give your project a name and clock OK.
4. You'll be prompted to pick a template from the Azure Gallery 
1. Select the "Website" template
1. 
2. Note:  What is a "template"? Templates are THE way that you create resources in the "new" Azure Portal. This template will have all the components needed for us to create an Azure website (or other Azure resources).
5. Next you'll be asked to pick an ASP.NET Project type
1. Doesn't matter much, but for this demo let's just pick an Empty Web Project template

Now that you've created the Azure Cloud Application project, let's take a look at the solution.

We have 2 Projects in our solution, first is our Web Project, and the second is this new thing called a Deployment Project.

The Deployment Project is what we will use for deployment of our Azure Website template that you just selected. So later on here we are going to use the Deployment Project to create an Azure Resource Group with Azure resources (like websites) in it. 

The Deployment Project has two json files that enable us to create Azure resource. One json file is called Website.json. You can think of this file as containing the "code" needed to create Azure resources (like a website). The other file is called Website.dev.param.json. This file contains the values for a few parameters that our Website resource is going to need (specifically: location, a name, and a web host plan).

And let's not forget we have a PowerShell file here that includes some scripts for working with Azure Resource Manager. But, we won't be using that today.

Right now, the Deployment Project is only available through the Azure Cloud Application template.

Create a Web Deployment Package of our Project

We need something to deploy, so we need to make a web deployment package.

1. Right click on the Web Project - select Publish
2. Click "Custom" to create our own Publish profile, call it whatever you want
3. Click Next
4. Select "Web Deploy Package" for the Publish Method option
5. Type a location for the package .zip file
6. That's it. Click Publish

We now have a web deployment package (.zip file). This is the website we are going to publish later on. But first we need to put this file somewhere where Azure Resource Manager can access it. An Azure Storage Account is a good place for this.

And if you have the Azure SDK, then uploading this zip file will be a breeze (if not there are some great 3rd party tools). To upload the file, navigate to Server Explorer -> Azure -> Storage. Create a storage account if you need one. Create a Blob container next. Double click on it. It should open in the document window. In the document window you can click the upload button now to upload your web deployment package. After you upload it you can also get the URL location of the package by right clicking on it and select "Copy URL" (you'll need to do this later)

That's it. Let's move onto creating some Azure resources using the Deployment Project.

Prep our Deployment Project

Open up the Website.json file. As I mentioned before, this file contains all the Azure resources that get created when you select an Azure Website template (things like the Website, Application Insights, a web host plan, and more). It also contains a list of parameters, like the website name (though their values aren't stored here, that gets stores in the Website.param.dev.json file).

You can scroll through the "resources" node to see all the resources that this template creates for you. What's here already may be just fine for you, and you don't need to necessarily edit any part of this file. But since this is an "advanced" scenario blog, we are going to edit it.

Just to make things a bit more advanced, I think we should deploy two websites here, and not just one (the template is currently configured to only deploy one website). So let's add a second website that will be our staging/development website.

To get another website added to our template is pretty simple, just edit the json file parameters section (in your Website.json file) and add in this highlighted json:

   "parameters": {
        "siteName": {
            "type": "string"
        },
        "siteName-staging": {
            "type": "string"
        },
        "hostingPlanName": {
            "type": "string"
        },

Now we have a new parameter for our "staging" website.

Then we need a resource to deploy the "siteName-staging" site. So add this json to your list of "resources" in your Website.json file:

   {
            "apiVersion": "2014-06-01",
            "name": "[parameters('siteName-staging')]",
            "type": "Microsoft.Web/sites",
            "location": "[parameters('siteLocation')]",
            "tags": {
                "[concat('hidden-related:', resourceGroup().id, '/providers/Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]": "Resource"
            },
            "dependsOn": [
                "[concat('Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]"
            ],
            "properties": {
                "name": "[parameters('siteName-staging')]",
                "serverFarm": "[parameters('hostingPlanName')]"
            }
        },

After you've done this, you'll have a resource template that creates TWO websites, and both of them will be in the same location (e.g. West US) with the same web hosting plan (if you wanted it in different locations or with different web host plans,you would need to add new parameters for those as well).

I want to deploy my Azure resources and publish my website at the same time. Right now all this template does is deploy Azure resources. So I need to add another resource in the list. Specifically, I want to add an MSDeploy resource to this file. The MSDeploy resource will take our web package and publish it to the website (specifically sitename-staging website) for us.

To add the MSDeploy resource, add the highlighted json into your siteName-staging website resource:

   {
            "apiVersion": "2014-06-01",
            "name": "[parameters('siteName-staging')]",
            "type": "Microsoft.Web/sites",
            "location": "[parameters('siteLocation')]",
            "tags": {
                "[concat('hidden-related:', resourceGroup().id, '/providers/Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]": "Resource"
            },
            "dependsOn": [
                "[concat('Microsoft.Web/serverfarms/', parameters('hostingPlanName'))]"
            ],
            "properties": {
                "name": "[parameters('siteName-staging')]",
                "serverFarm": "[parameters('hostingPlanName')]"
            },
            "resources": [
                {
                    "apiVersion": "2014-06-01",
                    "name": "MSDeploy",
                    "type": "Extensions",
                    "dependsOn": [
                        "[concat('Microsoft.Web/Sites/', parameters('siteName-staging'))]"
                    ],
                    "properties": {
                        "packageUri": "https://someStorageAcct/yourWebPackage.zip",
                        "dbType": "None",
                        "connectionString": "",
                        "setParameters": {
                            "IIS Web Application Name": "[parameters('siteName-staging')]"
                        }
                    }
                }
            ]
        },

I got this MSDeploy resource code by just looking at another Azure template, and taking what I needed out of it (there are a whole bunch of templates for Azure, and while they aren't all first class citizens in Visual Studio like the Website template, you can at least download them and open up the template's json file right in Visual Studio). This template's resource code is telling our website resource to also use the MSDeploy resource. And we are giving the MSDeploy resource the location of our web package (which should be some Azure storage account blob), and you can also set the values of any parameters for you web package here as well (which I've done with the "IIS Web Application Name" parameter).

So to recap, we have edited our template file so that it will create two website resources. And it will also use the MSDeploy resource to publish our web package to the staging website.

Deploy our Project

Its time to deploy our Azure resources and publish our website.

This is the easy part of the "advanced" blog.

Right click on the Deployment Project, select "Deploy to Resource Group".

1. Make sure you have a Subscription selected.
2. Click the Resource Group drop down and select "Create New"
3. Create a new Azure Resource Group (an Azure Resource Group is a way to manage all the resources used by your application, and this Resource Group will be the container for all of our resources that we are going to deploy)
1. 
4. Select a Deployment template (Website.json)
5. Select a Template parameter file (Website.param.dev.json)
6. Click "Edit Parameters"
1. Select the website names
2. Select the location (has to be a valid region, like "West US")
3. Select the web hosting plan name
4. Click Save
1. 
7. Select a Storage account next, this storage account is used to temporarily copy the template's json files to during the deployment process, and not for anything else
8. Click Deploy
9. 

In the Output window, you can follow along as the Azure resources are being created.

You should see something like this in the Output window:

11:55:39 - Starting deployment. This may take a while...
11:55:39 -    Uploading template to Azure storage account 'defaultstoragerms'.
11:55:39 -    Creating resource group 'MyAzureCloudApp' in location 'westus'.
11:55:40 -    Creating deployment 'VS_website' in resource group 'MyAzureCloudApp'.
11:55:40 -    Deployment created. Waiting for provisioning to complete...
11:55:50 -    Successfully provisioned resource 'WebHostPlan'.

After a minute or so it should all be done, and you can navigate to the Azure Portal to view your new Azure Resource Group, and the new websites inside of it.

And the coolest part, since your website has been published you can navigate directly to it.

Wrapping it up

That's it!

We took a quick look at how Visual Studio has some tooling now that allows you make a Web Project that uses the Azure Gallery Template.

You can edit these templates to customize your Azure resource deployments.

We did just this, and customized our template so that it deployed two websites instead of one, and so that the one of our websites used the MSDeploy resource to publish our web package.

This is an early release of our tooling, and I'd really love to hear any feedback you have about it our Azure Resource Manager in general.

Thanks, All 

Visual Studio Web Projects are a great way to create a web site (duh).

Recently I was deploying my VS Web Project to a “web package .zip” file. And then using the .zip file to publish my web site to Azure (using some Azure PowerShell cmdlets mainly).

This was going great, until I wanted to publish the Database Project and the Web Project at the same time. To do this I figured I’d just put the .dacpac file INSIDE of my web package .zip file.

Well, I couldn’t figure this out for the longest time and didn’t find much help online.

So I better write it down here, or who knows if I’ll ever remember it.

Simplest Walkthrough Ever – Make a dacpac

First you’ll want to make a SQL Database Project. This is pretty straightforward.

Create a New Project in Visual Studio and select “SQL Server Database Project”. After it’s created, right click the project and select “Add Table”. Add whatever kind of table you want here.

In the solution explorer, double click on “Properties”. For this example we are going to change the “Target Platform” type to be “SQL Azure Database”.

Now “Build” the solution. In your \bin\debug folder you will find the output which will be a “.dacpac” file. Save this for later.

Simplest Walkthrough Ever – Make a web project

Now we’ll make a simple web project. Create another project, and select “ASP.NET Web Application”. Let’s make an “Empty” web project here. We don’t need anything fancy.

Just build this project when it’s done creating. The output will also be in the bin\debug folder.

Simplest Walkthrough Ever – Make a Manifest.xml file

We need to make a “Manifest.xml” file now. This file will contain some parameters about are web package that we are going to build. And we will give the manifest.xml file as input to MSDEPLOY.exe

 The manifest file will be called Manifest.xml and will look like this:

<sitemanifest>
  <iisApp path="C:\Users\matt\Documents\Visual Studio 2013\Projects\YourSolution\YourWebProject" />
  <dbDacFx path="C:\Users\matt\Documents\Visual Studio 2013\Projects\YourSolution\DBProj\bin\Debug\DBProj.dacpac" />
</sitemanifest>

Alright, next thing is to write a MSDEPLOY command to consume this manifest file and output a web deploy package.

I’ve written out below the necessary steps I used to create a package using MSDEPLOY: 

Put that into a .BAT script, or type it from a command prompt.

This is going to create a web package, and correctly set the parameters for us inside of the web package.

Run it.

After this is done, you will have a Web Deploy Package .ZIP file that contains your dacpac AND your web project!

Publish it

Before you publish it, make sure you’ve already create an Azure Web Site and an Azure Database with the correct names as you’ve specified. You can do this right through the Azure Portal (http://manage.windowsazure.com).

The easiest way in the whole world to publish a web project to an Azure Website is to just use the Azure PowerShell cmdlets.

Here’s how you do that:

1) Download the Web Platform Installer - www.microsoft.com/web/downloads/platform.aspx

2) Search on “Azure PowerShell” and install it (you “may” have to reboot after install).

3) Open up Azure PowerShell as an Administrator.

-Set your execution policy for PowerShell using “Set-ExecutionPolicy RemoteSigned”

-Run “Add-AzureAccount” to add your Azure subscription to the session

-Run “Publish-AzureWebsiteProject –Name yourwebsite –Package .\yourwebpackage.zip”

4) Wait around 20 seconds

That should be it. Check it out on Azure and you should see that your database was updated and the website was updated.

Help, it didn’t work!

If it didn’t work here’s a couple things to try…

-Use the KUDU service to examine the data logs and see what the actual error was (navigate down to the .\data\msdeploy\ folder).

-Also you can try opening up the web deploy .zip package you made. Look at the “Parameters.xml” file in there. Make sure there’s no obvious path errors or anything like that. Also, make sure you don’t have “^^” double caret symbols either. If you do, you can easily just extract the zip file to a folder. Modify the parameters.xml file. And then ZIP the whole thing up again back into a .zip file.

I hope this was helpful. Let me know if it worked or didn’t work for you.

FOLLOW ME too – https://twitter.com/trampsanstom

THANKS!

-Matt Sampson

(Well I may be exaggerating a bit)

For a while now Microsoft has been working on improving our Develop and Test experience of web apps for all of our Azure cloud developers out there. Things are about to get a lot better with these new releases of the Azure SDK 2.3 and Update 2 RC.

One of the coolest contributions we had made in previous releases to Dev/Test is the ability to easily get Virtual Machines up and running in the cloud. These VM's could be setup to already have things like Visual Studio 2013 installed, SharePoint, or SQL, etc..

Starting with the new release of Azure SDK 2.3 and Update 2 (RC), you will also be able to provision a Windows Server VM that has IIS and Web Deploy enabled! This effectively gives you a web server in the cloud that you can develop and test your web apps against.

How cool is that?! 

This is good news for those of us who are interested in IaaS (Infrastructure as a Service), and awesome news for those of us who are cloud web developers.

No more setting up ON-PREM IIS machines with Web Deploy for web development for me. I’ll just be having Visual Studio make one up in Azure for me when I need it. Plus then I get the benefit of developing and testing my web app completely in the cloud.

Today I’m just going to do a simple walk through of these features here.

Go get your box setup before we get rocking:

-Go download Visual Studio 2013 Update 2 RC.

-Go get the Azure SDK 2.3 (for VS 2013) using Web Platform installer

-Go download the Azure PowerShell latest using Web Platform installer

Show me the experience!

Let's walk through a simple end to end scenario here to show off the new features we've added around the Dev/Test experience.

We'll start by launching VS, making a web app project, and creating a VM with IIS and Web Deploy already enabled.

Launch Visual Studio.

Select File->New Project.

We'll pick the ASP.NET Web Project template. Hit OK, and you'll see the ASP.NET project dialog now looks like:

We've got this new option in the bottom right of the wizard that will let us automatically create an Azure Web Site or Virtual Machine resource at the same time we make our project. We'll select the Virtual Machine option from the combobox. Hit OK.

You may need to login to Azure at this point (or sign up for free if you have an MSDN Subscription)

At this point you'll see a dialog to create a new Virtual Machine:

You can provide a few parameters here specifying what type of VM you want.

1) OS Image - you can select from any User Images, MSDN Images, or Microsoft Windows Images

2) VHD Size - pick a size for you VM

3) Enable IIS and Web Deploy - check this box if you want your VM to automatically have IIS and Web Deploy. Who wouldn’t want this?

4) Region - You can either select an Affinity Group, Virtual Network and Subnet, or an Azure region here which will designate where you VM should be created

Once you are done, hit OK. And now you’ll see some output messages about how the VM is being created up in Azure and then about how it is being configured. Be patient here as this can take over 10 minutes to complete (if you selected “Enable IIS and Web Deploy” it will likely take at least 10 minutes)

If you want, you can hop over to the Azure portal and see how it’s made a new Cloud Service and Virtual machine. It also added a storage account as well (this is needed for the Virtual Machine’s VHD).

Until this completes, you’ll notice that some resources have been added to your solution – 2 PowerShell scripts, and 1 JSON configuration file.

Let’s take a look at these.

PowerShell (PS) scripts and a JSON file

These PS scripts have a lot of power built into them. They can do a number of things for you to make your cloud development and testing easier. These scripts know how to create Azure web sites, publish to Azure web sites, create Azure VM’s, publish to Azure VM’s, and create SQL Azure DB’s as well in the case of Azure web sites.

The scripts don’t have any dependencies on VS. And can run on completely separate machine. They can be automated in a build environment. They can be shared with the other developers on your team. The scripts themselves don’t “change” from project to project.

So what is this JSON configuration for? This is consumed by the PS Scripts (it is NOT consumed by VS or the Web App Publish Wizard). It basically contains either all the parameters needed to create or publish to an Azure web site (like the name, the region, etc), or, in this example, it contains all the parameters needed to create or publish to an Azure VM.

You’ll see it’s got all the information regarding the VM we setup. It has the size, name, region, OS, the endpoints that it’s going to open, etc.

Looking at it you’ll see that VS has added coloring and formatting for JSON files. Sweet!

Open up any of the PS Scripts in the VS Editor. You’ll see that we now have coloring for PS Scripts as well.

Again - How cool is that!?

You can also right click on any PS Script and open it up in the PowerShell ISE. Let’s do that now. Right click on the .PS1 script and open it up in the PowerShell ISE.

We are now going to walkthrough creating a VM using the PS Scripts. Before we get started here, a few pre-requisites:

1) You need to have at least PowerShell (PS) 3.0 installed (find out what version you have by typing “$PSVersionTable” in PS.)

2) You need the latest version of Azure PowerShell as mentioned earlier (you can get this through the Web Platform installer)

a. You’ll need to run the “Add-AzureAccount” script to add your Azure credentials.

3) You need to set your PowerShell’s execution policy to be RemoteSigned or Unrestricted.

4) For this example to work, you’ll need a Web package that we’ll publish. Create one through the web app we just made by right clicking the Web Application project and selecting Publish. Then during the Publish Wizard make sure you publish it a web (.zip) package.

5) (YOU MAY HAVE TO DO THIS STEP) You might have to import Azure PS module for the very first time. You can do this with this PS command:

Import-Module ‘[SYSTEM DRIVE]:\Program Files (x86)\Microsoft SDKs\Windows Azure\PowerShell\Azure\Azure.psd1’

Now for some PS Action

Alright, that’s out of the way. Let’s get started using this PS script

The PS1 file that is opened in our PS ISE is the main “entry” point that we’ll use to generate or publish to our Azure resources (i.e. Azure web sites and Azure VMs). The PSM1 file is a module file, or a library basically of some commonly used PS functions.

You can always use the “Get-Help” PS cmdlet to find out more about what these PS scripts do (e.g. GET-HELP .\ScriptName.ps1).

We’re going to do a couple things here with our PS Scripts:

1) Create an Azure VM that has IIS and Web Deploy enabled

2) Publish a web package to it

Before we do this we need to modify our JSON configuration file. You can do this right from VS if you want.

You’ll want to change the following 2 parameters – the Virtual Machine name and the Cloud Service name. Give both of these a unique name. You can also specify the VM user’s password right in the JSON file (if you don’t want to do it here, you’ll need to do it on the PS command line).  You can certainly change more parameters if you want, but this is the minimum we’ll need to create a new Azure VM.

You can certainly skip this step. And just publish the web package the VM we’ve already made. Nothing wrong with that. If you want to do that then just do nothing to the JSON file (except you will have to type in your password and save it, unless you want to pass in the password on the PS command line to the PS Script like so: –VMPassword @{name=’myname’;password=’mypassword’}  )

Save your changes to the JSON. Switch back to the PS ISE.

Type the following:

> <Name Of Your PS1>.ps1 –Configuration .\configurations\<name of your JSON>.json –Verbose –WebDeployPackage <path to your web package> -AllowUntrusted

The “-Verbose” flag isn’t necessary, but I like to know everything my scripts are doing, and the –Verbose flag will output all the scripts runtime messages for you.

The “-AllowUntrusted” flag is necessary. And this is because the Azure VM’s Web Deploy certificate we are deploying to is not a trusted certificate.

Let’s run this command run now. It could take a while (around 10-20 minutes. Most of that time is setting up IIS and Web Deploy.).

Once it’s done, (and the PS Script will tell you when it’s done), you should be able to launch your web site, which will be something like: .cloudapp.net/">http://<myVMname>.cloudapp.net/

Wrap it up

There’s more to show off here that I’ll have to do in another blog post.

But to summarize what we did:

1) Created an Azure VM with IIS and Web Deploy as part of our web project creation experience

2) Automatically had some PS Scripts and a JSON configuration file added to our solution to give us more flexibility when creating and publishing web apps to Azure

3) Used those PS Scripts and JSON file to create an Azure VM and publish a simple web app to it.

You can find a LOT more about the PS Scripts on this great MSDN Article:- Using Windows PowerShell Scripts to Publish to Dev and Test Environments

Hopefully this IaaS and Dev/Test demo was useful to you.

Let me see any feedback you have!

Find me on Twitter - https://twitter.com/TrampSansTom

And big thanks to my co-worker and friend Raghuveer who helped with this article (find him on Twitter as well - https://twitter.com/hey_krish)

Thanks – Matt Sampson

So you've installed Azure PowerShell.

Now you are asking yourself "WHAT VERSION OF AZURE POWERSHELL HAVE I INSTALLED?!"

First, stop screaming. Find that Caps Lock Key.

Updated way: The easiest way in the world to do this – launch an Azure PowerShell session. And then type the following:

> get-module azure

ModuleType  Version    Name                                ExportedCommands                                                                                                                   
----------       -------    ----                                ----------------                                                                                                                   
Binary            0.7.4      Azure                               {Add-AzureAccount, Add-AzureCacheWorkerRole, Add-AzureCertificate, Add-AzureDataDisk...}   

You can see right in the output there is the version of Azure (0.7.4) in this case.

A secondary way to do this is to actually look at the web request itself:

1) Use the Web Platform Installer to install the latest Azure PowerShell version (http://www.microsoft.com/web/downloads/platform.aspx)

2) Launch an Azure Powershell session

3) Run the Add-AzureAccount command and add your azure account

4) Install and launch Fiddler - http://www.telerik.com/fiddler (I can't do my job without Fiddler, so keep this thing around)

5) Enable HTTPS Decryption in Fiddler (takes 2 clicks to do -http://docs.telerik.com/fiddler/Configure-Fiddler/Tasks/DecryptHTTPS )

6) Run some benign Azure PowerShell command now like "Get-AzureLocation"

7) Look at the awesome output in Fiddler - find your Web Request, select it, then on the right side of the screen select INSPECTORS tab and then the HEADERS sub tab

8) You should see some Client: User-Agent header like -

At the end of the User Agent is the version – v.0.7.4 in this case.

HTH! – more posts coming soon

Matt Sampson

KUDU is one of those neat little things that is developed here at Microsoft that I seem to just accidentally stumble into (like SignalR).

So in this blog, I’m going to give a brief demo of how you can use the KUDU diagnostic service with your own LightSwitch Web Apps that is deployed to a Windows Azure Web Site. But truthfully, you could use this with any azure web site (not just LightSwitch).

If you are someone who loves having debugging tools at your disposal like, KUDU, and you use Azure Web Sites, then this blog is for you :).

Publish a LightSwitch Web App to an Azure Web Sites

I won’t be going over how to publish a LightSwitch app to an Azure Web Site since there are already so many walkthroughs on how to do this (like this one - How to: Publish a LightSwitch Application to Windows Azure). But you will need to get this step done before we can continue. If you already have a recent deployment, then we can use that too.

Launch the Azure Portal and navigate to your Azure Web Site. You should see an option to “Set up deployment credentials” (unless you have already done this in the past, in which case you should have these credentials setup already).

Go ahead and click this link. Then setup your login and password. The KUDU service requires credentials before you can use it, and it’s going to use these credentials that you just setup.

Check out the KUDU Service

We’ll get to collecting a memory dump from our web site in a minute, but first let’s just look at the KUDU service some more.

The KUDU service has something like a “Dashboard” that you can access (with your credentials): https://”mywebsitename”.scm.azurewebsites.net

The dashboard looks like this:

There’s some information on how to use the REST API (which we’ll do later on), and at the top there are some other functions, like “Debug Console”. Which is very cool IMO.

If you select Debug Console and then click the Sites folder, you’ll see something like this:

These are the web app’s files on some machine up in the “cloud”. All the files you published are up here.

I fell out of my seat with excitement when I first saw this. You can do some great stuff here like edit the web.config file (to do something like enabling tracing), or add new files (as I have done with the cleverly named “New Text Document.txt”).  You could do these things before of course through other methods, but this streamlines the whole experience and makes it more familiar to use.

Get a Memory Dump

We will now use the KUDU Service to get ourselves a dump of the process that hosts our web application. All the different ways to get various types of process DUMP files are documented on the KUDU GitHub site.  Remember any requests you make are going to be counted as part of your usage quota for your Azure Subscription.  The one we are going to get is a GCDUMP, which is a memory dump and something we can look at using VS 2013 Ultimate. 

Launch a PowerShell script. And input the following script call to the KUDU service to retrieve the first process (i.e. w3wp.exe) and get a GCDUMP of it:

Invoke-WebRequest -uri https://<Website>.scm.azurewebsites.net/diagnostics/processes/0/gcdump 

-credential <YourDeploymentUser> -outfile .\dump.diagsession

 Follow me on Twitter -  https://twitter.com/TrampSansTom