Anthony Chu

Three weeks ago I attended and spoke at .NET Fringe in Portland, OR. I fell in love with the conference and the city. It was an amazing experience.

Saturday, July 9

Geek Train

The .NET Fringe Geek Train from Seattle to Portland was a great way to kick off the conference. Adron Hall organized it and met us at Seattle's King Street Station with our tickets.

Update - December 23, 2016

Article and samples have been updated to work with the latest microsoft/iis image, Docker, and Windows Server 2016 updates.

Update - November 12, 2017

Check out this better approach for applying config transforms in your ASP.NET apps in Windows containers.

In the last article, we walked through how to run an ASP.NET 4.6 application in a Windows Server container. In that example, we didn't have a way of applying environment-specific transformations to the Web.config. Today we'll look into how to do that.

Environment Variables in Docker

If the exact same Docker image is deployed to different environments, how do we manage environment-specific settings in each running container? The answer to this is environment variables. When we first start up a Docker container (e.g., using docker run), we can pass one or more environment variables to the container. These variables are available to the application or script that is launched as the entrypoint of the container.

In ASP.NET 4.6 and earlier, it's common to use configuration transformations to change values in the Web.config to the correct settings for the environment. When we start a container for the first time, we can pass an environment variable into the container to signal which config transformation to apply.

Update - December 23, 2016

Article and samples have been updated to work with the latest microsoft/iis image, Docker, and Windows Server 2016 updates.

Ever since ASP.NET Core came out, a big deal has been made that it runs on Linux and we can finally deploy ASP.NET inside Docker containers. While there's no doubt that it's a huge step forward for the platform; there's one thing that is often overlooked... This is only good news for green field projects and apps that can be ported to ASP.NET Core.

The majority of existing ASP.NET apps will never be ported to ASP.NET Core. There are many reasons an app can't be ported:

• Too many dependencies on System.Web
• WebForms!
• Third party dependencies that haven't been ported to .NET Core
• It runs perfectly fine in .NET 4.6 and earlier and doesn't make financial sense to port it

This is why Windows containers are so important. They let us bake our existing applications into Docker images and deploy them with the same tools as the rest of the Docker ecosystem.

Today we'll look at what it takes to build and run an ASP.NET 4.x WebForms app in a Windows container. We'll be using Windows Server Core 2016 TP5.

I noticed my previous article on hooking up LUIS to an Azure Functions Bot Framework bot was mentioned in a great article comparing different bot frameworks by the folks at Aspect Software. There was one problem, however; it wasn't immediately obvious to the author of the article or their readers that my code was a hack to get the Bot Framework to work with Azure Functions. It's not representative of how one would write a Bot Framework bot in C# or Node.

So I thought today I'd write about how Bot Framework and LUIS were meant to be used together. I presented a similar example at the Vancouver Polyglot Unconference last week on chatbots. I am choosing to use Node here for no other reason than I'm more familiar with the Node Bot Framework SDK right now. A C# version would be quite similar.

A couple weeks ago, Jef King, Clint Singer, and I presented at the Vancouver Azure Meetup about the different ways to deploy ASP.NET on Azure. It was a lot of fun!. In this post, I'll summarize our presentations.

There are a few ways to deploy ASP.NET Core on Azure:

• Virtual Machines and VM Scale Sets
• Cloud Service Web Roles
• App Service (Web Apps)
• Container Service
• Service Fabric