It's seems not too long ago I was laying down the words for "So Many Ways to Learn .NET in 2020", but of course it was March yesterday too.

This list is still very valid; 101 videos (youtube | channel9), Microsoft docs, the various shows now available on the new https://live.dot.net and LearnTV too!

But wait there's more...

A New Microsoft Learning Path for C#

Build .NET applications with C# is a new learning path with 6 modules to get anyone started with creating apps from scratch with C#. Start with a basic introduction, move into working with projects and dependencies, debugging and more. In little more than 3 hours, get a refresher or a whole new start with .NET and C#.

Want a challenge?

Join the .NET Skills Challenge for the month of November.

Compete against friends and coworkers by completing interactive modules on how to build apps across multiple platforms with .NET and earn your rank on the leaderboard.

Over 40 hours of FREE Learning inside of this awesome collection of 8 Paths and 5 additional bonus modules.

Topics include Basic C# skills, Web API development, Blazor Apps, Static Web Apps, Xamarin and Visual Studio or VS Code.

Get started by going to https://aka.ms/dotnetskills

Let me know how you're doing

Tweet me @spboyer, how are you doing on the leaderboard? Are there more modules you'd like to see for C# or other .NET related topics?

Have fun, it's FREE and for you!

Did you know that every month, the docs team at Microsoft has a post for what's new in the .NET documentation?

For each month there are new articles, updates to existing docs, and kudos for the community contributors.

It's super easy to get involved in contributing to the docs for the related technologies you are invested or interested in.  See the Microsoft docs contributors guide or simply click the "Edit" link at the top of any doc to get started, they are all open source!

Here are some of the highlights for last month .NET Docs

The Architecting Cloud-Native Apps for Azure architecture guide e-book added some new sections -

• Caching in a cloud native app
• Database per microservice
• Elasticsearch in in a cloud native app

C# language revised the Value types and added new <inheritdoc> xml documentation

.NET added a great new article in the .NET Guide on How to migrate from Newtonsoft.Json to System.Text.Json

Other areas of the docs are also adding similar related what's new pages too. Check out ASP.NET Core docs updates and Xamarin updates too!

The docs continue to grow and evolve. Check in often on these pages to keep up to date with the latest content.

I have been running the well known ghost blogging platform on Azure AppService since ghost was version 0.10, about 8 years. In fact, it was before Azure had resource groups.

This means that it's Node on Windows Servers and I'm doing a bit of maintenance for upgrading the version of the platform. Running things like gulp.js scripts for builds and so and hoping for Kudu to do my git deployment after a couple of tries because I am running on a small box and there are limitations for networking and npm and start scripts to complete in enough time.

After a few successful upgrades, it became overwhelmingly painful to try and make the updates and life, work, etc. got in the way and now ghost is on version 3.2 and I am far too behind to try and do a manual update. So the jump to containers makes sense.

The data conversion was a little more work as I had to install ghost 1.0, import my data > export it and then import to 3.0.

Choosing the setup

I am using the latest ghost:3.2-alpine image available on Docker Hub.  

$ docker run -d -p 3001:2368 ghost:3.2-alpine

It uses SQLite by default as the backend, but also offers MySQL which I'll use as an option through MySQL on Azure.

Analytics

I have been using Google Analytics for the past 12 years on my blog and want to continue with this solution. However, if you're starting a new solution, Application Insights is a quick click option when creating your AppService instance.

Create a new Dockerfile and add Application Insights in this manner:

FROM ghost:3.2-alpine

# Add app-insights globally
RUN npm install -g applicationinsights

# Link app insights to avoid rebuild/validate projects npm package tree
RUN cd current && npm link applicationinsights 

# ENV APPINSIGHTS_INSTRUMENTATIONKEY xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx
RUN sed  -i.bak -e "/var startTime = Date.now(),/a appInsights = require('applicationinsights'), " \
                -e "/ghost, express, common, urlService, parentApp;/a appInsights.setup().start();" current/index.js

You'll need to build your own Dockerfile and host it in a repository. i.e. Azure Container Registry, Docker Hub, GitHub etc.

This adds the npm package for Application Insights and adds the script to the index,js files of the application. Be sure to add your APPINSIGHTS_INSTRUMENTATIONKEY environment variable to your App Service Configuration.

Azure Web App for Containers

As I mentioned, the previous version was hosted in Azure App Service on Windows (Node 10 + Windows). Now we are moving to Linux (Alpine) on Web App for Containers.

Creating the app service was really simple. A single command line got the job started for me.  (ok maybe 2, need a service plan too)

# Created my S1 service plan
az appservice plan create -n spboyerblog20 -g spboyer --is-linux - "East US" --sku S1 --number-of-workers 1

# Create the app service with the alpine 3.2 ghost image
az webapp create -n spboyer -g spboyer -p spboyerblog20 -i ghost:3.2-alpine

MySQL

I have setup the database backend using Azure Database for MySQL selecting bare minimums and an auto growth option - Basic, 1 vCore(s), 10 GB.

The data connections are set as ENV variables in my application settings.

Using a service for my data takes care of the potential data loss should the container fail. However, there are files like my themes and images that I want to make sure I don't lose if the container decides to restart or when I put in a customer container and CI/CD.  Enter -> Azure Storage and Path mappings in Web App for Containers!

I created a File Share in my storage account called contentfiles, where I can upload/update this content as well as interact with it using any SDK or even an Azure Function.

Next, to map the path to the container set it in the Path mappings section of my configuration.

Be sure to set the ENV in configuration  
paths__contentPath to /var/lib/ghost/content_files

This can also be done using the Azure CLI, however I found it easier using the GUI for this task.

az webapp config storage-account add -g <resource-group> --custom-id Content-name [Storage Account Name] --share-name contentfiles --access-key [Storage Account Key] mount-path /var/lib/ghost/content_files

Other configuration settings

• NODE_ENV : production
• url : <appname>.azurewebsites.net OR your custom domain (cause links to break)
• WEBSITES_PORT : 2368 (internal port for ghost) - this my be a regression for auto detecting port used by containers.
• PORT : 2368  (internal port for ghost) - this my be a regression for auto detecting port used by containers. not a duplicate

Additional Notable changes

I run Cloudflare for DNS and caching, so there were some changes I needed to make for my custom domains. The DNS changes took about 30 seconds to make the A, CNAME and TXT updates. Either it's much easier or I know what I'm doing.

Caching was purged, pushed a button and SSL - done, comes free with Cloudflare.

After all that, very happy. Was great and Azure was super easy to get setup on containers and now I am positioned for CI/CD on GitHub Actions or Azure DevOps or whatever I want. Bring on the updates!

It's a new year and sure to be on your list, as well as mine, is learning. Here is a quick list of some .NET learning resources for you to check off that resolution for 2020.

.NET 101 Videos - dot.net/videos

In September of 2019, many members if the .NET team created over 100 videos for topics including C# 101, .NET, desktop apps, ASP.NET web apps, learning containers and Docker. More have been added recently including a whole series around creating and managing NuGet packages.

All of the videos are available on YouTube or Channel 9.

Microsoft Learn

Microsoft Learn allows you to master core concepts at your speed. Take 15 minutes to complete a module or start a whole learning path  over a course of an hour or multiple hours on your schedule.

C# Modules

Over 20 Modules on C# available.

ASP.NET / .NET Core Modules

Create a web API with ASP.NET Core - Create a RESTful service with ASP.NET Core that supports Create, Read, Update, Delete (CRUD) operations.

Create a web UI with ASP.NET Core - ASP.NET Core supports creating webpages using a built-in templating engine called Razor. In this module, you'll learn how to create webpages using Razor with ASP.NET Core.

Secure an ASP.NET Core web app with the Identity framework - Add authentication and authorization to an ASP.NET Core web app using the Identity framework.

Persist and retrieve relational data with Entity Framework Core - Query and manage relational data in a .NET Core app with an Object-Relational Mapper.

Docs, Docs, Docs!

There are so many pages of tutorials, reference pages, SDK, and examples in the docs. https://docs.microsoft.com/ is the entry point, however here are the .NET related pages for you.

• .NET Docs
• ASP.NET Core Docs
• Xamarin Docs
• .NET on Azure

Others

• On.NET Show - Channel 9 show hosted by Cecil Phillip cecilphillip, Rich Lander @runfaster2000 and other guest hosts. Great content where they look at the APIs, the tooling, and some of the interesting projects being created in the .NET ecosystem.
• Azure Friday - Join Scott Hanselman, Donovan Brown, or Lara Rubbelke as they host the engineers who build Azure, demo it, answer questions, and share insights.
• Cloud Native Show - Follow Shayne as he explores Microsoft campus to get the definition (and more) straight from engineers and product teams.

This is in no way an exhaustive list, there are many blogs, and other video resources out on the web. Feel free to comment with your favorites!

Do you run an open-source project? Use Visual Studio Code and its extensive set of extensions when maintaining your project or even coding day to day?

If you have an extension or set of them you prefer/recommend for your projects; you can enable other contributors by informing them with an alert showing any like.

Clicking on Show Recommendations opens the Workspace Recommendations

Details allows you to also ignore Ignore the recommendation as well.

Enabling in your repository

Add a .vscode folder, if not already there for your debugging setup, and create a new file named: extensions.json with the following structure.

{
	"recommendations": [
		"msjsdiag.debugger-for-chrome"
	]
}

The recommendations[] contains the extensions identifier from the Visual Studio Marketplace.

If I were to add recommended extensions for the ASP.NET Core Workshop for instance. The extensions.json file would likely look something like this.

{
	"recommendations": [
                "ms-vscode.csharp",
                "VisualStudioExptTeam.vscodeintellicode",
                "ms-mssql.mssql",
                "ms-vscode.azure-account",
                "ms-azuretools.vscode-azureappservice",
		"ms-azuretools.vscode-docker",
                "MS-vsliveshare.vsliveshare-pack"
	]
}

• C#
• Visual Studio Intellicode
• SQL Server
• Azure Account
• Azure App Service
• Docker
• VS Live Share Pack

Simple and clean

A small addition to help contributors discover extensions you utilize as well as use to add to the projects you're maintaining, and completely optional.

In my previous post, I showed how to take a WCF service and containerize it using Visual Studio. By doing so, this gives us the opportunity to push our heritage (aka legacy) application to the cloud either in Azure App Service using Web App for Containers, Azure Container Instances (ACI), or in the event we need something like an orchestrator Kubernetes is available in AKS.

Many times we would like to use the new technology with the old. For instance, creating a .NET Core Razor Pages application or .NET Core Web API to consume the WCF application.

However, the new applications will be using Linux containers and everything must be scalable and run in a Kubernetes cluster.

Let's see how we can use AKS with the new Windows Container support to accomplish this!

Setting up the Windows enabled AKS Cluster

NOTE: please read related docs, there are some Before you begin items that are important to have set up.

• Install the aks-preview CLI Extension
• Register Windows preview feature

Create the cluster

A couple of notes here is you must create the cluster using the Azure Network plugin (Azure CNI) as well as a Windows Admin Password for any Windows Server Containers created on the cluster.

GROUP="demo-aks"
CLUSTER_NAME="demo-cluster"

# user and password needed for the Windows nodes if we create a Windows node pool
PASSWORD_WIN="P@ssw0rd1234"
USER_WIN="azureuser"

az group create -l eastus -n $GROUP

#create the aks cluster
az aks create \
    --resource-group $GROUP \
    --name $CLUSTER_NAME \
    --node-count 1 \
    --enable-addons monitoring \
    --kubernetes-version 1.14.0 \
    --generate-ssh-keys \
    --windows-admin-password $PASSWORD_WIN \
    --windows-admin-username $USER_WIN \
    --enable-vmss \
    --network-plugin azure

The script creates a single node and master controller, all Linux. From here we can now add the Windows node pool for the WCF Service.

# create the windows node pool
az aks nodepool add \
    --resource-group $GROUP \
    --cluster-name $CLUSTER_NAME \
    --os-type Windows \
    --name npwin \
    --node-count 1 \
    --kubernetes-version 1.14.0

After the new Windows node pool is creates, kubectl get nodes shows Ready for deployments.

NAME                                STATUS   ROLES   AGE    VERSION
aks-nodepool1-48610275-vmss000000   Ready    agent   10m    v1.14.0
aksnpwin000000                      Ready    agent   110s   v1.14.0

Deploy the applications

In order for proper deployment to the Windows node pool, specify a nodeSelector in the spec of your chart.

spec:
      nodeSelector:
        "beta.kubernetes.io/os": windows

Here is a sample of the deployment file for the PeopleService WCF example I'll use and have already containerized and pushed to my Azure Container Registry.

When you're using Azure Container Registry (ACR) with Azure Kubernetes Service (AKS), an authentication mechanism needs to be established. See Authenticate with Azure Container Registry from Azure Kubernetes Service documentation on how to enable.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: peoplesvc
  labels:
    app: peoplesvc
spec:
  replicas: 1
  template:
    metadata:
      name: peoplesvc
      labels:
        app: peoplesvc
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": windows
      containers:
      - name: peoplesvc
        image: shayne.azurecr.io/peopleservice:latest
        ports:
          - containerPort: 80
  selector:
    matchLabels:
      app: peoplesvc
---
 apiVersion: v1
 kind: Service
 metadata:
   name: peoplesvc
 spec:
   type: ClusterIP
   externalName: peoplesvc
   ports:
   - protocol: TCP
     port: 80
   selector:
     app: peoplesvc

The Service type is set to ClusterIP here so only an internal IP is allocated. Next, a .NET Core Razor Pages application is deployed in a Linux container to the Linux pool.

Same is true, container pushed to ACR. Following chart is the deployment file for the web application.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: peopleweb
  labels:
    app: peopleweb
spec:
  replicas: 1
  template:
    metadata:
      name: peopleweb
      labels:
        app: peopleweb
    spec:
      nodeSelector:
        "beta.kubernetes.io/os": linux
      containers:
      - name: peopleweb
        image: shayne.azurecr.io/peoplewebapp-core:latest
        env:
        - name: "SERVICE_URL"
          value: "peoplesvc"
        ports:
          - containerPort: 80
  selector:
    matchLabels:
      app: peopleweb
---
apiVersion: v1
kind: Service
metadata:
  name: peopleweb
spec:
  type: LoadBalancer
  ports:
  - protocol: TCP
    port: 80
  selector:
    app: peopleweb

Notable points.

• ENV variable : SERVICE_URL used for the application to communicate with the WCF service. Notice that it is a DNS name.
• Service type: LoadBalance allocating a public IP address for external access.

The web app to service calls via DNS is made possible via Azure virtual network enabled by Azure CNI.

Deploy the applications, use the following command.

kubectl apply -f people.web.yaml -f people.wcf.yaml

Once the deployment is complete, kubectl get all shows:

NAME                             READY   STATUS    RESTARTS   AGE
pod/peoplesvc-7b46dfc9c5-gjwsc   1/1     Running   0          1d
pod/peopleweb-5dbfbf5578-8dqs2   1/1     Running   0          1d

NAME                 TYPE           CLUSTER-IP    EXTERNAL-IP    PORT(S)        AGE
service/kubernetes   ClusterIP      10.0.0.1      <none>         443/TCP        1d
service/peoplesvc    ClusterIP      10.0.41.1**   <none>         80/TCP         1d
service/peopleweb    LoadBalancer   10.0.81.1**   40.**.52.***   80:31654/TCP   1d

NAME                        READY   UP-TO-DATE   AVAILABLE   AGE
deployment.apps/peoplesvc   1/1     1            1           1d
deployment.apps/peopleweb   1/1     1            1           1d

NAME                                   DESIRED   CURRENT   READY   AGE
replicaset.apps/peoplesvc-7b46dfc9c5   1         1         1       1d
replicaset.apps/peopleweb-5dbfbf5578   1         1         1       1d
replicaset.apps/peopleweb-794f5b5bb8   0         0         0       1d

Further details are available in the Kubernetes dashboard via az aks browse --name <clustername> --group <resource-group>

Browsing to the site https://ipaddress/People

Summary

This is a great scenario and solution for anyone looking to use the new technologies while also having an opportunity to move legacy heritage application to the cloud and orchestration the entire architecture. Scaling, DevOps, containers and more cloud native practices are leveraged in new and old.

There are a number of reasons for moving long-standing .NET Framework applications like WCF, and ASP.NET Webforms to containers and then into containers or "modernizing legacy heritage apps".

1. DevOps - Once the application is set up in a container, build a CI/CD pipeline to build and push the applications to the cloud in a streamlined fashion.

2. Velocity - In addition to the CI/CD features, the ability to version the container, ease of deployment and rollback in the event of failures is easier.

3. Leverage other cloud services - Add Application Insights or logging, managed database services, and other PAAS offerings.

Where to start

Visual Studio 2019 has the Docker tooling built into the workloads. You will need to install Docker for Windows and ensure Windows Containers are enabled.

Open your WCF application in VS 2019, right-click the project file and select Add -> Docker Support.

The Docker tooling for Visual Studio will inspect the application and add the appropriate Dockerfile for your application.

In the case of WCF, the following Dockerfile is added to your solution.

FROM mcr.microsoft.com/dotnet/framework/wcf:4.7.2-windowsservercore-ltsc2019
ARG source
WORKDIR /inetpub/wwwroot
COPY ${source:-obj/Docker/publish} .

Now when you run your application, select "Docker" from the Debug menu and the WCF Test Client will launch and add the container url for the service.

If the WCF Test Client does not load, be sure to check that the workload is selected in the Visual Studio 2019 Installer.

Upon looking at the *csproj file, you should see that there are new entries for starting the new container with F5.

<DockerLaunchAction>LaunchWcfTestClient</DockerLaunchAction><DockerLaunchUrl>http://{ServiceIPAddress}/MyService.svc</DockerLaunchUrl>

The WCF Client will start and add the new container URL endpoint to test against instead of http://localhost.... All of your breakpoints and debugging will now happen within the container as the debugger is attached to the container as opposed to the local machine host.

Building the Docker Image

When you click Debug or press F5, the image is built for your application by Visual Studio, after the base image is pulled. This may take some time as this is a Windows Container image and ~1.59 Gb compressed.

If you are familiar with Docker, you're likely to try and use the standard docker build or docker run commands. However, will fail using the command line if the proper MSBuild command is not run to produce the appropriate output.

We have to build the WCF application first either using Visual Studio or MSBuild. The Docker tooling for VS, actually runs an MSBuild command behind the scenes to create the obj/Docker/publish folder, compile the app and copy the output there prior to running the docker run command.

This is important in the event we move to a DevOps scenario. The command need to run on the command line and in Azure DevOps is:

msbuild /t:ContainerBuild /p:Configuration=Release

Pushing the image to a registry

Give a project name i.e. hellowcf will produce a docker image named hellowcf:latest. From here, you may want to tag the image with an appropriate version number, or other identifier prior to pushing it to a registry.

For example, tagging with a buildId and pushing it to an Azure Container registry.

docker tag hellowcf:latest myregistry.azure.cr/hellowcf:1234

docker push myregistry.azure.cr/hellowcf:1234

Using Visual Studio

Visual Studio has a rich UI for publishing your applications and with containers, the same is true.

The publish dialog has options for deploying to a container registry (Azure Container Registry, Docker Hub, Custom) or deploying the built container image direct to Azure App Service right from the UI.

Publishing the application

In this scenario, a WCF application was used however it could as easily have been an ASP.NET WebForms app or a console service.

For the WCF app, Windows Containers on AppService is a great first step and if you have a number of components to your architecture that is needing to spin up at once; AKS - Azure Kubernetes Service now supports Windows Containers as well.

Console apps or services that run once and while, or on timers to perform work is when a service like Azure Container instances is a great fit.

The point here is getting your long-standing and stable applications into a container without re-writing or re-architecting the solution and still take advantage of cloud native type practices.

Additional Reading

Deploying Existing .NET Apps as Windows Containers

The GitHub event announced a great new feature - GitHub Sponsors. GitHub Sponsors is a new way to financially support the developers who build the open source software you use every day. See the full announcement blog post for more information.

Recognizing Contributors

Recently, Brian Clark introduced me to all-contributors (https://github.com/all-contributors/all-contributors) an awesome way to recognize contributors to your project.

The installation is super easy. Enable the bot on your repository, and you're ready to go.

Good practice is to have a CONTRIBUTING.md in your repo not only to encourage good practices but to also set expectations and standards.

Adding contributors

There are a few ways in which our contributors get added to the table on the README.

First, this is a go forward bot for contributions/commits; therefore they are added as commits happen.

For other ad-hoc acknowledgments, you may comment on a PR or Issue.

The comment may also be a bit more intentional. Per the docs, it uses basic Natural Language Processing.

Here, I added Jen Looper for her design work.

In either case, a PR is opened to add the user/contributor to the README and .all-contributorsrc files for the attributions.

Building community through code is at the heart of GitHub, but being a good human through good manners is the first step to continuing that effort. Say thank you to your contributors. It takes a few moments, they will thank you with more commits.

Many years ago I wanted to jump into a project in open source but had no idea where to start. I had worked with node.js, .NET and some other web-based technology but wasn't sure where to start and GitHub was new to me. Ironically, I fell onto Omnisharp and the .NET Core yo aspnet projects through my Microsoft MVP Summit meetings that year.

Flicking through Twitter, as one does, I came across an announcement from a friend Tierny (@bitandbang) where he had started a CLI tool for node.js projects called "good-first-issue" to find random GitHub Issues for projects submitted to his tool.

There are a ton of open source projects asking for help on issues that have a low barrier to entry. These issues are typically tagged or labeled with good-first-issue, up-for-grabs, helpwanted, etc. Finding them can be hard, a good start is https://up-for-grabs.net .

up-for-grabs.net

There are over 700 projects currently available on the site. Everything from C++, Java, TypeScript, Ruby, Django, Go and more is available in the filters.

If you have a project and are looking for help get it added by submitting your own project(s) via their GitHub - https://github.com/up-for-grabs/up-for-grabs.net. There is even a yeoman generator for getting the yaml correct - yo up-for-grabs.

upforgrabs - .NET Projects

As a .NET developer, I wanted to create something like Tierny had, so I went the global tool route.

Using the latest .NET Core 2.2 SDK, created upforgrabs.

Install it now dotnet tool install -g upforgrabs

https://github.com/spboyer/upforgrabs

The source of the data is, in fact, the same project list from https://up-for-grabs.net, which is filtered specifically to .NET type projects.

Getting the data

Each project for the site is stored in a yaml file under up-for-grabs.net/_data/projects/. However consuming 700 or so yaml files, filtering, etc. on every call from a console app is not very efficient.

The solution, Docker and Azure Container Instances. Here I used a .NET Core Alpine Linux container and installed Subversion.

Why Subversion? GitHub does not have a way to get a specific folder from a repository. Using Subversion I downloaded the /projects folder to process all the files.

# install subversion for alpine
RUN apk --no-cache add subversion
# download the data for projects
RUN svn export https://github.com/up-for-grabs/up-for-grabs.net/trunk/_data/projects data

Once the yaml is downloaded, using Newtonsoft.JSON, they are combined and converted to a single project.json file.

var files = from file in Directory.EnumerateFiles(@"data", "*.yml", SearchOption.AllDirectories)
                  select new
                  {
                    File = file,
                    Lines = File.ReadAllText(file)
                  };

      Console.WriteLine("Processing files...");
      foreach (var f in files)
      {
        //Console.WriteLine("Processing " + f.File);
        try
        {
          var deserializer = new Deserializer();
          var content = new StringReader(f.Lines);
          var yamlObject = deserializer.Deserialize<Project>(content);

          result.Add(yamlObject);
        }
        catch (Exception ex)
        {
          errors.Add(new Error() { name = f.File, info = ex.Message, exception = ex.Source });
          continue;
        }
      }

      JsonSerializer serializer = new JsonSerializer();
      using (StreamWriter sw = new StreamWriter(outputPath))
      using (JsonWriter writer = new JsonTextWriter(sw))
      {
        serializer.Serialize(writer, result);
      }

      PostFile(outputPath).Wait();
    }

PostFile() writes the final file to an Azure CDN using the Azure SDK.

See my previous post on using an Azure CDN and serverless to speed up API calls.

private static async Task PostFile(string file)
    {
      CloudStorageAccount storageAccount;
      CloudBlobContainer cloudBlobContainer;

      string storageConnectionString = Environment.GetEnvironmentVariable("storageconnectionstring");
      if (CloudStorageAccount.TryParse(storageConnectionString, out storageAccount))
      {
        try
        {
          // Create the CloudBlobClient that represents the Blob storage endpoint for the storage account.
          Console.WriteLine("Checking for/creating blob container");
          CloudBlobClient cloudBlobClient = storageAccount.CreateCloudBlobClient();
          cloudBlobContainer = cloudBlobClient.GetContainerReference("up-for-grabs");
          await cloudBlobContainer.CreateIfNotExistsAsync();

          // Set the permissions so the blobs are public.
          BlobContainerPermissions permissions = new BlobContainerPermissions
          {
            PublicAccess = BlobContainerPublicAccessType.Blob
          };
          await cloudBlobContainer.SetPermissionsAsync(permissions);

          Console.WriteLine("Pushing to CDN");
          CloudBlockBlob cloudBlockBlob = cloudBlobContainer.GetBlockBlobReference("projects.json");
          cloudBlockBlob.Properties.ContentType = "application/json";

          await cloudBlockBlob.UploadFromFileAsync(file);

        }
        catch (StorageException ex)
        {
          Console.WriteLine("Error returned from the service: {0}", ex.Message);
        }
        finally
        {
          Console.WriteLine("Process complete.");
        }
      }
    }
  }

Keeping it Fresh w/ Azure DevOps

In order to keep the project.json feed up to date, I set up a scheduled build using Azure Devops and Container Instances.

• Runs nightly
• Builds the container, getting the new YAML data
• Pushes to Azure Container Registry
• Runs the container in Container Instances, pushing the json file to the CDN
• Destroys the Container Instance ensuring only runtime billing.

Here is the build pipeline YAML

resources:
- repo: self
queue:
  name: Hosted Ubuntu 1604
steps:
- task: Docker@1
  displayName: 'Build Docker Image'
  inputs:
    azureSubscriptionEndpoint: 'shboyer (5ca082f3-***)'
    azureContainerRegistry: shayne.azurecr.io
    arguments: '--no-cache'
    imageName: 'up-for-grabs-feed:$(Build.BuildId)'
    includeLatestTag: true

- task: Docker@1
  displayName: 'Push to ACR'
  inputs:
    azureSubscriptionEndpoint: 'shboyer (5ca082f3-***)'
    azureContainerRegistry: shayne.azurecr.io
    command: 'Push an image'
    imageName: 'up-for-grabs-feed:$(Build.BuildId)'

Upon successful build, the Release Pipeline executes. This has the Start/Destroy of the ACI Container.

az container create \
    --resource-group up-for-grabs \
    --name firsttimersfeed \
    --image $(acrLoginServer)/up-for-grabs-feed:$(Release.Artifacts._up-for-grabs-feed.BuildId) \
    --dns-name-label up-for-grabs-feed \
    --restart-policy OnFailure \
    --registry-login-server $(acrLoginServer) \
    --registry-username $(acrName) \
    --registry-password $(acrPassword) \
    -e 'storageconnectionstring'='$(storageconnectionstring)'

Cleanup of the container

az container delete -n firsttimersfeed -g up-for-grabs -y

The repository for the "feed project" is available here - https://github.com/spboyer/up-for-grabs-feed.

Feedback

There are more than 290 .NET open source projects currently in the list. If you're looking for a new project to get into, this is an easy way to get there.

Open a command line and type upforgrabs.

Let me know what you think!

If nothing else is true, containers have made local development on a platform so much easier. If you want to use SQL Server for your backend just docker pull microsoft/mssql-server-linux and you can start up an instance with a few parameters.

Azure CosmosDB is not available as a container, however, MongoDB is available and happens to be a database I have used in previous applications. MongoDB is one of the many APIs that CosmosDB supports; locally I can develop against an instance of Mongo either in a container or installed and simply change the connection string for my production instance.

The flexibility of being able to use MongoDB and then just changing a connection string to use CosmosDB is a nice capability if you have exisiting applications that are using Mongo and you are looking for the globally scalable and features that CosmosDB offers.

If you need to migrate data from MongoDB applications to CosmosDB see this doc for the steps.

Creating the Databases

For MongoDB locally, using Docker is super simple. Run docker pull mongo, and now you can use this in your application.

docker run --name mongo mongo

Visual Studio Code has a CosmosDB extension as a part of the Azure Extension pack that allows you to interact with Mongo Databases as well as CosmosDB instances.

This extension also allows you to create your CosmosDB instance right from VS Code, or you can create it in the Azure portal or even using the Azure CLI.

However you like to create the instance, it can all happen in the same tool and that's awesome for me.

Local Development

The app is a basic ASP.NET Core Razor Pages application which list "Running Races" that have been reviewed.

Both the app and the database are set to use containers and docker-compose to orchestrate them.

Application Dockerfile

FROM microsoft/dotnet:2.1.2-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 443

FROM microsoft/dotnet:2.1.403-sdk AS build
WORKDIR /src
COPY runracereview.csproj .
RUN dotnet restore
COPY . .
WORKDIR /src
RUN dotnet build -c Release -o /app

FROM build AS publish
RUN dotnet publish -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "runracereview.dll"]

docker-compose

version: "3"
services:
  runracreview:
    container_name: runracereview
    restart: always
    build:
      context: ./runracereview
      dockerfile: Dockerfile
    environment:
      - ASPNETCORE_ENVIRONMENT=Development
      - ASPNETCORE_URLS=http://+:80
    ports:
      - "57270:80"
      - "44348:443"
    volumes:
      - ${HOME}/.microsoft/usersecrets/:/root/.microsoft/usersecrets
      - ${HOME}/.aspnet/https:/root/.aspnet/https/
    links:
      - mongo
  mongo:
    container_name: mongo
    image: mongo
    volumes:
      - ${WEBAPP_STORAGE_HOME}/site:/data/db
      #- ./data:/data/db
    ports:
      - "27017:27017"

Notice that in the compose file that the mongo image has a volume mapped to ${WEBAPP_STORAGE_HOME}/site:/data/db, this is done to persist the test data locally as to not reload the data everytime the container is spun up.

Check out the Microsoft Learn course : Build a .NET Core app for Azure Cosmos DB in Visual Studio Code - FREE

Setting up the app

Getting the connection to the database are done using the Configuration settings base on the Environment.

In appsettings.Development.json, the configuration for Mongo is added, and for Production, the CosmosDB connection string is set in appsettings.Production.json. The ConfigurationBuilder loads the appropriate file based on the environment.

  "MongoDB": {
    "ConnectionString": "mongodb://localhost:27017",
    "Container" : "mongodb://mongo:27017",
    "Database": "Races"
  },

Startup.cs configures the Settings options.

 services.Configure<Settings>(
      options =>
      {
        options.ConnectionString = Configuration.GetSection("MongoDb:ConnectionString").Value;
        options.Database = Configuration.GetSection("MongoDb:Database").Value;
        options.Container = Configuration.GetSection("MongoDb:Container").Value;
        options.IsContained = Configuration["DOTNET_RUNNING_IN_CONTAINER"] != null;
      });

If you are running .NET Core applications in a container you can inspect the Environment variable DOTNET_RUNNING_IN_CONTAINER to determine if this is true.

If the application is running in a container and in Development then the Settings class returns the proper connection string for the container.

Simple but ...

Being able to work locally and iterate on a simple set of data without having to hit the production data constantly, or be concerned with the UH OH moments when trying new things is an advantage of this setup.

Code for this application is available on GitHub : https://github.com/spboyer/runracereview

Keeping your code update to with the latest references can at times be a challenge with the rate of speed third-party dependencies can revise. However, with security patches and bug fixes constantly plaguing us it is a necessary exercise.

I have been using dotnet-outdated to quickly run checks on my projects and it has even been a huge help when getting some non-descript error messages in my code realizing I was missing a recent update.

Looking at a way to extend this functionality or automate it, I came across Nukeeper and a write up from Scott Hanselman that mentioned that this one had a Repository Feature where running the command nukeeper repo <myrepo> would do the similar functions as dotnet outdated, BUT would also send a PR to the project!

This got me thinking, what if I could use NuKeeper and Azure Devops to watch my repo? I already have a pipeline building and deploying the project when commits are being made to a branch; we could set up an additional pipeline to do this process and when PRs are sent build the project for validation as well.

Setting up NuKeeper in Azure DevOps

The first step is to make sure that you have a GitHub personal access token or PAT. This is needed for executing the repo command of NuKeeper.

I set my PAT as a variable "Nukeepeer__github__token" for the pipeline.

Moving over to the pipeline, the first task here is to install the .NET Core SDK that I want to target. In this case 2.1.403.

The next task uses the dotnet command to install the NuKeeper global tool, for local dev; dotnet tool install -g NuKeeper.

There are two additional steps here to set the git user and name. These steps are needed only due to personal access token being used does not have a publically exposed email address. Typically you'd have this configured on your local machine in your .gitconfig.

Now that the SDK and global tool are set, the final task in the pipeline is the command to check our repo. Here the repo command is configured to use the PAT variable $(NuKeeper_github_token) and we are passing additional options for getting updates for 3 weeks or older minor changes.

nukeeper repo "https://github.com/spboyer/runracereview" $(NuKeeper_github_token) --age=3w --change=minor

Here is the Azure DevOps Pipeline in YAML.

queue:
  name: Hosted Linux Preview
variables:
  NuKeeper_github_token: 'your_github_personal_access_token'
steps:
- task: DotNetCoreInstaller@0
  displayName: 'Install .NET Core SDK'
  inputs:
    version: 2.1.403


- task: DotNetCoreCLI@2
  displayName: 'dotnet global tool install'
  inputs:
    command: custom

    custom: 'tool '

    arguments: 'install -g NuKeeper'


- script: 'git config --global user.email %git_email%' 
  displayName: 'Set git email address'

- script: 'git config --global user.name %git_username%' 
  displayName: 'Set git user name'

- script: 'nukeeper repo "https://github.com/spboyer/runracereview" $(NuKeeper_github_token) --age=3w --change=minor' 
  displayName: 'Run Race Review Project'

Scheduling Checks

Under the Triggers tab we can set a schedule as to when to run the pipeline. Every Saturday at 3 AM, it will run the checks and perform the Pull Requests to notify our other pipeline that there are needed updates to run tests, build and deployments against.

The most recent run revealed that there were needed updates -

2018-10-15T18:05:51.1414374Z Found 2 packages in use, 2 distinct, in 1 projects.
2018-10-15T18:05:51.1414982Z Bogus, MongoDB.Driver
2018-10-15T18:05:52.1161425Z Found 1 possible updates
2018-10-15T18:05:52.1162171Z Bogus from 23.0.3 to 24.3.0 in runracereview/runracereview.csproj
2018-10-15T18:05:52.1162436Z 
2018-10-15T18:05:52.1182228Z Found 1 package update
2018-10-15T18:05:52.1208829Z Bogus to 24.3.0 from 23.0.3 in 1 place since 13 days ago.
2018-10-15T18:05:52.2247646Z Selection of package updates: 1 candidates
2018-10-15T18:05:52.2248371Z Selected package update of Bogus to 24.3.0
2018-10-15T18:05:52.2334021Z Updating'Bogus' from 23.0.3 to 24.3.0 in 1 projects
2018-10-15T18:06:03.1689000Z Making PR onto 'https://api.github.com/ spboyer/runracereview from nukeeper-update-Bogus-to-24.3.0
2018-10-15T18:06:03.9890259Z Adding label(s) 'nukeeper' to issue 'https://api.github.com/ spboyer/runracereview 5'
2018-10-15T18:06:04.2032755Z Done 1 updates

Sending the PR over.

The whole process now being automated using Azure DevOps and a .NET Core global tool. That's pretty slick. How are you keeping your apps up to date?

The Docker extension for VS Code was recently updated to better support .NET Core applications and the experience is super nice!

The extension already has great support for building your containers, pushing images to Docker Hub, Azure Container Registry and tasks such as running a specific image or tagging an image too. However, adding a Dockerfile to an ASP.NET Core application was not updated to support the microsoft/dotnet base images.

The Docker extension can be downloaded separately or is also available as a part of the Azure extension pack for VS Code which provides a number of other extensions for working with the many cloud services without leaving the editor.

First, I'll start by creating a quick Razor Pages app with the .NET CLI, change to the output directory and open in VS Code.

> dotnet new razor -o dotnet-docker-vscode
> cd dotnet-docker-vscode
> code .

Using the extension, I can now add the needed Dockerfile using the Command Pallete, CMD + Shift + P (MacOS) or Ctrl + Shift + P (Win), type Docker and the options are presented.

The extension adds the appropriate Dockerfile for ASP.NET Core 2.1

FROM microsoft/dotnet:2.1-aspnetcore-runtime AS base
WORKDIR /app
EXPOSE 80

FROM microsoft/dotnet:2.1-sdk AS build
WORKDIR /src
COPY ["dotnet-docker-vscode.csproj", "./"]
RUN dotnet restore "./dotnet-docker-vscode.csproj"
COPY . .
WORKDIR "/src/."
RUN dotnet build "dotnet-docker-vscode.csproj" -c Release -o /app

FROM build AS publish
RUN dotnet publish "dotnet-docker-vscode.csproj" -c Release -o /app

FROM base AS final
WORKDIR /app
COPY --from=publish /app .
ENTRYPOINT ["dotnet", "dotnet-docker-vscode.dll"]

Again using the extension we can build the image. When doing so it does ask for a tag, and in this case I will prefix it with my Azure Container Registry name for pushing to later.

Expanding the Images section, we can see the shayne.azurecr.io/dotnet-docker-vscode image available now. Right-clicking the entry show the options you would expect; aligning with the most common commands from the Docker CLI.

The option I can select here is to Push the image now to my Azure Container Registry.

You may need to authenticate to your ACR which can be accomplished in the terminal using az acr login --name {name of your registry} should you get an error when pushing your image.

Now that the image is available in my private registry I can use the App Service extension to create an instance of the application using App Service on Linux and push my container.

All of these tasks we can accomplish without leaving Visual Studio Code. There are a bunch of great extensions for developing whatever language or stack you like. For .NET Core, Azure and Docker development the following are some of my favorites.

• Azure extension pack
• Docker extension for VS Code
• GitLens
• mssql
• Kubernetes

Challenge

There is a challenge here for you...go download the extension. Build something, publish it and let me know. I want to hear the feedback on the extension and experience.

Since .NET Core was announced, I've really been loving the command line experience for .NET Core. Being able to use dotnet new to start a new application regardless of the OS or what shell/terminal experience is on a machine is the way to happiness.

The Azure Functions team has put together some fancy new templates for creating serverless apps now.

Getting the new templates installed

.NET Core templates are all just NuGet packages and installed using dotnet new -i <package-path>. In this case, the templates are on a private feed, so you need to get them nupkg files from https://functionscdn.azureedge.net/public/cli-feed-v3.json.

The latest current version right now is from the feed:

    "2.3.3": {
      "Microsoft.NET.Sdk.Functions": "1.0.14",
      "cli": "https://functionscdn.azureedge.net/public/2.0.1-beta.34/Azure.Functions.Cli.win-x86.2.0.1-beta.34.zip",
      "nodeVersion": "8.11.1",
      "localEntryPoint": "func.exe",
      "itemTemplates": "https://www.myget.org/F/azure-appservice/api/v2/package/Azure.Functions.Templates/2.0.0-beta-10224",
      "projectTemplates": "https://www.myget.org/F/azure-appservice/api/v2/package/Microsoft.AzureFunctions.ProjectTemplates/2.0.0-beta-10224",
      "templateApiZip": "https://functionscdn.azureedge.net/public/TemplatesApi/2.0.0-beta-10224.zip",
      "sha2": "4A2B808E86AE4C4DEF38A2A14270D19EC384648AD1FDF635921A64F609D41098",
      "FUNCTIONS_EXTENSION_VERSION": "beta",
      "requiredRuntime": ".NET Core",
      "minimumRuntimeVersion": "2.1"

Download the projectTemplates and itemTemplates nupkg files and install them using the command:

dotnet new -i ~/Downloads/Azure.Functions.Templates.2.0.0-beta-10224.nupkg"
dotnet new -i ~/Downloads/Microsoft.AzureFunctions.ProjectTemplates.2.0.0-beta-10224.nupkg"

Now when dotnet new is run, the Azure Function templates are available.

Templates                                         Short Name                          Language          Tags
-------------------------------------------------------------------------------------------------------------------------------
QueueTrigger                                      Queue                               [C#]              Azure Function
HttpTrigger                                       Http                                [C#]              Azure Function
BlobTrigger                                       Blob                                [C#]              Azure Function
TimerTrigger                                      Timer                               [C#]              Azure Function
DurableFunctionsOrchestration                     DurableFunctionsOrchestration       [C#]              Azure Function
SendGrid                                          SendGrid                            [C#]              Azure Function
EventHubTrigger                                   EventHub                            [C#]              Azure Function
ServiceBusQueueTrigger                            SBQueue                             [C#]              Azure Function
ServiceBusTopicTrigger                            SBTopic                             [C#]              Azure Function
EventGridTrigger                                  EventGrid                           [C#]              Azure Function
Azure Functions                                   azureFunctionsProjectTemplates      [C#]              AzureFunctions/ClassLib

Creating a quick function app

# initial a new Azure Function application
dotnet new azurefunction --output myfunctionapp

# change dir
cd myfunctionapp

# add a new HttpTrigger Function 
dotnet new http --name echo 

# directory
.
├── echo.cs
├── host.json
├── local.settings.json
└── myfunctionapp.csproj

Now that I have initialized my app and first function, I could start the app using the functions cli with func host start but I want to be able to be able to debug the app, and deploy. I can open the project using VS Code using code . or in my case I use the Insiders Build code-insiders .

I have the Azure Extension Pack for VS Code installed which includes the Azure Functions extension which allows you quickly browse, create, manage, deploy, and even debug functions locally.

I am prompted with a notification that this is an Azure Function created outside of VS Code, and it is asking to add the assets for setting up debugging. Click Yes.

Now I can hit F5, add break points, and inspect my code just as I would expect from a great tooling experience but also have the ability to add new functions. Using the integrated terminal in VS Code you can see that the endpoint http://localhost:7071/api/echo is available.

If we wanted to add an additional HttpTrigger, use the following command:

# using -n as the short form for --name and -na short for namespace
dotnet new http -n echo2 -na myfunctionapp 

Or if you prefer a UI experience in VS Code, there is the Functions Extension for adding a new one as well.

• Click on the "Add new function"
• Select the folder you want to work in
• Select the type of function
• Type the name of the function
• Type the name of the namespace
• ... potentially other options.

Both options are great depending on how you like to work. The templates are in line with how I work for all .NET Core applications now and I spend much of my time using command line tools like Docker, Kubernetes and the Azure CLI.

The Azure Functions are open source at https://github.com/Azure/azure-functions-templates please provide feedback. Azure Function development, debugging and deployment in Visual Studio is available as well.