Microsoft Bot Framework – Part 2: Publish Bot Service to Azure

This blog post is Part 2 of how to create a chat bot with Microsoft Bot Framework which can answer FAQs on your website. This is in continuation to my previous post where I explained how to create a QnA service using Microsoft QnA service maker. You can read Part 1 of my post here.

In this post, I will demonstrate how to deploy the service we previously created on Azure. The only pre-requisite is to have an Azure account. You can sign up for free.

  • Log in to your Microsoft Azure account and search for “Microsoft Bot Framework”, you should get one result “Bot Service”. Select the Bot Service to proceed and click Create. At the time of writing Bot Service is still in preview.Azure-BotService
  • Next, provide the name of your app, select hosting plan and click Create. The app service will be created within few minutes.
  • Next, select the service created in the last step and you will get a screen similar to below.


  • Follow the steps to register your bot with Microsoft App Id.
  • In the next step, choose the language you are comfortable in developing your bot framework. Currently, C# and NodeJS are supported.

Note:  Your initial code will be auto-generated when you create a bot. So, you do not need to jump to the code right away.

  • Next, you get an option to choose a template. Select template Questions and Answer and click Create.


  • In the next step, you can integrate the QnA service created in Part 1.  Sign in with your QnA maker account credentials, select your existing knowledge base from the drop-down and click OK.



  • This will provision your bot and deploy your Bot Service. It can take few minutes to complete this step.
  • Next, you will be asked how to work with your code. You can choose to edit in online editor, download source code Zip or set up continuous deployment from your source control.
  • That’s it, you can now test your Bot by clicking “Test”  button on the top right.



In the next post, I will explain how to connect to different channels like Skype, Web Chat, Facebook Messenger etc. from your Bot Framework.

Stay Tune! 🙂


async await best practices

aysnc await is probably one of the most important features of C#. It has made the life of developers easy. It helps developers to write clean code without any callbacks which are messy and difficult to understand.

However, if used in incorrectly async await it can cause havoc. It can lead to performance issues, deadlocks which are hard to debug. I have burnt hands due to incorrect use of  async await in the past and based on my little experience I can tell these issues will make your life hell, you will start questioning your very existence on this earth or why you chose to be a developer 🙂

I have tried to add common pitfalls while using async await  below. These are some of my learnings while working on problems that arise due to incorrect use of async await Much of these is inspired from Stephen Cleary blogs and Lucian Wischik six essential tips for Async channel 9 videos.

Here are tips:

  • AVOID using Task.Result or Task.Wait(). They make the calls synchronous and block async code.
  • Make your calls async all the way.
  • USE `Task.Delay` instead of `Thread.Sleep`
  • Understand the difference between CPU bound and IO bound operation before using Task Parallel Library or TPL
  • USE Task.Run or Parallel.ForEach for CPU bound operation.
  • USE await for IO bound operation.
  • USE ConfigureAwait(false)on the web APIs or library code. On the WPF application do not use ConfigureAwait(false) at the top level methods.
  • AVOID using `Task.Factory.StartNew`. Use Task.Run
  • DO NOT expose a synchronous method as asynchronous or visa vesra. In other words your library method should expose the true nature of method.
  • DO NOT use async void other than top level Events. ALWAYS return async Task

I hope these tips help few of you and help avoid common mistakes. Please suggest any other tips in the comments section.

Clean Visual Studio Solution

Today, every project we work on big or small, easy or complex, small team or large team  is probably on Source Control. The source control of course can be git, VSTS, SVN etc.

Still, there are times where you need to share your code as zip in an email, or shared link. It could be because your customer, colleague or partner do not have access to your source control or simply you have not added your code to Source Control itself.

Now, if you just zip the solution folder and email or share the link then you would include folders like bin, obj, packages or files like .sou, .user etc. These files are not required to build the solution. These files increase your zip file size significantly. The solution is simple, delete all the files which are not required. However, what if you have over 50 projects in the solution? And what if you have to this activity multiple times? It is too much of manual effort to do perform this activity.

I had a similar issue in my one of  my engagements recently.  However, instead of spending hours to do this manual work, I decided to automate the process by creating a small console app. The app deletes all the unwanted folders and files recursively from the solution. I have included following folders and files as per my requirements as the part of  deletion list:

Folders:  bin, obj, TestResults, packages
Files:  "*.vssscc", "*.ncrunchproject", "*.user", "*.suo"

Source code has been shared in GitHub here.

Alternatively, You can also download the executable directly from here.

Hope it helps some you to save your time and be more productive. Please do provide your comments and feedback.

Dispose HttpClient or have a static instance?

Recently, I came across this blog post from ASP.NET Monsters which talks about correct using HttpClient.

The post talks about issues of related to disposing HttpClient object for each request. As per the post calling HttpClient method can lead to issues.

using (var httpClient = new HttpClient())
    await httpClient.GetAsync(new Uri(""));

I have been using the HttpClient object like this for almost all of my projects. Hence, this post was an eye opener for me.

Also, as per the patterns and practices documentation:

In a web application this technique is not scalable. Each user request results in the creation of a new HttpClient object. Under a heavy load, the web server can exhaust the number of sockets available resulting in SocketException errors.

From above two articles I could conclude, below are the major issues with disposing the HttpClient object for each request:

  • The execution time of the HttpClient request is higher. This is obvious since we create and dispose the object every time for a new request.
  • Disposing HttpClient object every time could potentially lead to SocketException. This is because disposing the HttpClient object does not really close TCP connection. Quoting from the ASP.NET monster post:

..the application has exited and yet there are still a bunch of these connections open to the Azure machine which hosts the ASP.NET Monsters website. They are in the TIME_WAIT state which means that the connection has been closed on one side (ours) but we’re still waiting to see if any additional packets come in on it because they might have been delayed on the network somewhere

I wanted to test the performance improvements when we create a static instance of HttpClient. The aim of my test was ONLY to see the difference of execution time between the two approaches when we open multiple connections. To test this, I wrote following code:

namespace HttpClientTest
   using System;
   using System.Net.Http;

   class Program
      private static readonly int _connections = 1000;
      private static readonly HttpClient _httpClient = new HttpClient();

      private static void Main()

      private static void TestHttpClientWithUsing()
             for (var i = 0; i < _connections; i++)
                using (var httpClient = new HttpClient())
                   var result = httpClient.GetAsync(new Uri("")).Result;}
         catch (Exception exception)

     private static void TestHttpClientWithStaticInstance()
             for (var i = 0; i < _connections; i++)
                  var result = _httpClient.GetAsync(new Uri("")).Result;
         catch (Exception exception)


For testing:

  • I ran the code with 10, 100, 1000 and 1000 connections.
  • Ran each test 3 times to find out the average
  • Executed ONLY one method at a time

My machine configuration was:

System Configuration

Below are the results from the Visual Studio Instrumentation Profiling:

Method No Of Connections Time in Seconds Difference in Seconds Performance Improvement in %
TestHttpClientWithUsing 10 2.6
TestHttpClientWithStaticInstance 1.8 1 44
TestHttpClientWithUsing 100 408
TestHttpClientWithStaticInstance 240 168 70
TestHttpClientWithUsing 1000 241
TestHttpClientWithStaticInstance 160 81 51
TestHttpClientWithUsing 10000 2456
TestHttpClientWithStaticInstance 1630 826 51

As you can see the time of execution for the static instance is far lesser than disposable object.

Does it means we should use static client object all the time? It depends.

One of the issues people have found with static HttpClient Instance is that it does not support DNS changes. Refer this article. For .NET application, there is a workaround available where you can you can set connnectonLeaseTimeOut by using ServicePoint object as mentioned in post.

However, for an ASP.NET Core, you may be out of luck as per this issue in GitHub as similar property does not seem to exist.

Hope this post help you take informed decision in your projects. Please share your thoughts in comments section.