When we are developing a Bot for Teams using .Net Core, we can publish the code for our Bot into Azure to see our work in action.
But its difficult to attach a debugger when our process is running in Azure.
So if we want to debug our Bot whilst developing to trace its execution or monitor unit tests – what do we do?
Well, we can use a utility titled Ngrok to temporarily give the Bot running on our Local Machine a public facing WAN Address that Azure can communicate with – but as the code is still running on our Local Machine, we can trace its execution in our Visual Studio Debugger even as different public processes in Teams and Azure communicate (and so wait for) our Bot running locally.
The following will get this up and going for us:
Get Ngrok
Download Ngrok from https://ngrok.com/
This downloads an EXE file which is our command line way of running Ngrok.
Start our Ngrok Forwarding URL
Run Ngrok as Admin and enter the following command to open localhost port 3978 publicly:
Ngrok http -host-header=rewrite 3978
NOTE: The Port here for 3978 should match the output that Visual Studio is running – which may vary from machine to machine.
This will start the mirroring of localhost to a public address – the console output showing the detail of this in action:
Point our Web App Bot to our Ngrok Forwarding URL
Our next step is to point our Azure Bot Channel to the newly created public facing address.
NOTE: This will break our Bot whilst it is pointing to our local address and not the real bot address! So this should only be done in a Dev Instance of the Bot, or by creating a 2nd Messaging Endpoint to work with.
We can do this by opening our Web App Bot definition in Azure.
Within here, we then navigate into Configuration and look at the Messaging Endpoint setting.
This will typically be an Azure URL based on our Bot App’s Name – such as: https://mybusinessbotsso.azurewebsites.net/api/messages
We can swap out this URL and replace it with our Ngrok URL. (making sure to use the https address)
Once applied – now any call to the Bot will be ramped through Ngrok to our locally running of the code, and so captured by the debugger in Visual Studio:
This allows us to trace the execution and compare our workings to the eventual outcome of our code in Teams.
So we can see the same outcome here, but having traced the working through the debugger.
Is this the best way?
This gives us a great way of debugging our Bot and has some advantages when it comes to debugging messages from other sources – say if we are posting to our Bot from Power Automate or Dynamics.
But it comes with some disadvantages.
If we turn off Ngrok then our Bot ceases to function, as it will be looking for a Endpoint Messaging URL that no longer exists.
Similarly it can only really work for one developer at a time – as the entire instance of the Bot is rerouted to a single workstation. (so again, never use it for a Bot that’s running for anything other than Development!)
We can work around some of these disadvantages by creating a new Bot Channel Registration and then connecting this Registration to our Local Messaging Endpoint rather than affecting the Bot in Azure.
