In previous articles I explained how you can build bots using the Microsoft Bot Framework and the Azure Bot Service. The latter is built on top of Azure Functions, one of my favorite components in Azure. Both the Functions and Bot teams are releasing stuff in a fast pace, but sometimes this leads towards the two not being 100% in sync with each other. This post addresses one of these issues, namely the Bot Service having old-style templates for new instances.
When you create a new Bot Service instance and download the code, you get a solution with .CSX files. These are used in Azure Functions and they still work great. The issue though is that when you load these in Visual Studio and want to debug your code locally, there’s no IntelliSense to go with them. Althought this is on the teams backlog, it’s not there yet and if you’re a VS dev like I am, you probably can’t live without it š
.NET Class library as Function App
Two months ago, Donna Malayeri (who’s doing absolutely awesome work on the Functions team) wrote this postĀ detailing how you can build a web project which uses the local functions runtime to host and debug the code. This brings two great worlds together: it allows you to build code in Visual Studio with all the benefits (Intellisense!) whilst utilizing the func.exe CLI runtime as well.
The post does a very good job at explaining how to set this up, but what if you want this for your Bot Service instances?
Converting a Bot Service
To convert your bot service instance to a Web Project, here’s what you need:
- A web project (well duh…).
- The CSX files that you want to convert to ‘regular’ C# classes.
- The function.json file that defines the endpoint for your bot.
- A appsettings file should you have one. This is typically where your Microosft App ID and password are stored.
- The project.json file. You don’t really need this, but it’s handy to look up which packages your instance is using.
And here’s the steps:
- Follow Donna’s post to set-up a new web project.
- When creating the classes, create one for your dialog and one for your entry point. You can combine them as well of course, but I personally like to separate them. In the example these are namedĀ Dialog.cs andĀ DialogEntryPoint.cs.
- DialogEntryPoint.cs will contain the contents from the ‘run.csx’ file. This the entry point that’s being called when the user communicates with your bot. It’s referenced inĀ function.json as follows:
123456789101112131415161718{"disabled": false,"scriptFile": "..\\bin\\FunctionsLibraryProject.dll","entryPoint": "FunctionsLibraryProject.DialogEntryPoint.Run","bindings": [{"type": "httpTrigger","direction": "in","webHookType": "genericJson","name": "req"},{"type": "http","direction": "out","name": "res"}]}
Note the scriptFile and entryPoint settings which point to the output DLL and the class/method which handles the incoming message. - Dialog.cs contains your dialog code.
- Ensure that you set-up the project to load the correct NuGet packages. Normally you will needĀ Microsoft.Bot.Builder.AzureĀ which will include some dependencies. If you include this, ensure the project is set-up to run .NET framework version 4.6 instead of 4.5.
Lastly, you need to configure the start options of the project. This is detailed in Donna’s post as well, but for your reference, below are the settings I used. Note that the location of func.exe might differ based on the installation type you used.
With everything configured, running the project should now start your bot in the func.exe runtime and hook up VS at the same time for local debugging! Awesome!
Sample @ github
If you’re struggling, I took the liberty of adjusting the sample project from the blog post and making a bot specific one from it. You can use it to see how it has been set-up. Be aware that my sample is based on the LUIS bot service, so it does require a settings file with your specific LUIS keys to actually work. Should you have any questions or remarks; feel free to leave them below!
Check out the code:Ā https://github.com/jsiegmund/BotAsWebProject
