Botbuilder-dotnet: Using botbuilder in combination with a .NET Core Azure Function

[devedse]

Introduction

I'm currently working on building a bot service using the latest .NET Core technology. I would like to set this up using Azure Functions as they are pay per use instead of having to pay for the complete month.

They way this worked within the bot builder framework is that I would create a .NET Standard project which contained all the bot logic. The .NET Framework Azure Function would then call into this code and it would work fine :smile:. However when I created a .NET Function to talk against the .NET Standard project I ran into DLL issues and ultimately found out that the issue was that the bot framework does not support .NET Core.

Issue

I then started migrating the code to the .NET Core version (this github) of the bot framework but I quickly ran into the issue that the new version of the bot framework requires a Startup.cs class, services, etc. which is all not available in .NET Core Azure Funcions.

Could someone provide a sample on how to do this? Or at least some guidance to help me find out where to start :smile:?

[drub0y]

Good news: this is totally possible today!

We're aware that we need to whip together some official docs/samples on Azure Function hosting (and maybe even a first class experience), but, for now, let me point you to this sample from @brandonh-msft where he has replicated the EchoBot sample in Azure Functions. Please note that, at the time of this writing, the master branch is still using an (much) older version of the Bot Framework SDK, but I just so happen to have PR'd an upgrade to the latest M3.1 bits yesterday which is available here.

[brandonh-msft]

Also worth noting, the bot doesn't work live (at least on Skype) due to issues w/ the SDK. Or did you not observe the same problem, @drub0y?

[drub0y]

@brandonh-msft That's a fair point, that needs looking into still. I think the main point here is your sample clearly demonstrates a working integration of the v4 Bot Framework within an Azure Function.

Right now the sample works great with the emulator for sure, so at least people can use the sample to start writing some code and we'll of course sort out whatever the internal issue is with integration with the actual Bot Service.

[devedse]

I just tried running the code with the bot emulator but ran into the following exception:

Also verified it on a colleagues computer and he ran into the same trouble. (We both use the latest pre-release version of Azure Functions CLI)

[drub0y]

TL;DR - Bottom line for now: non-authenticated emulator requests _SHOULD_ work, anything authenticated _WILL NOT_ work.

Ok, just wanted to give you an update here....

First, I want you to see that it does work in an unauthenticated scenario. Point your bot emulator here at my deployed instance with no credentials and see it work for yourself: http://drmarsh-echobot-function.azurewebsites.net/api/messages

Second, there is an actual bug with the code that I didn't notice because when you hit it directly as a "plain old" Azure Function with the emulator it's not an issue. Specifically the problem is that the header name it's using is wrong. It should not be "Authentication" it should be "Authorization". This is a required fix and I'll PR to @brandonh-msft ASAP, but the fact is it's just going to move us forward to the next breaking problem.

So the real problem is, as soon as you start using real credentials against this thing you're going to run into an issue. The issue that I'm seeing when I debug is that the Azure Functions 2.0 runtime (which we know is beta... right?) is throwing a FileNotFoundException when looking for the System.IdentitityModel.Tokens.Jwt assembly which then results in an AssemblyLoadException. Now, the file is totally there and I believe this to be a 2.0 functions runtime error. The short of it is I think this is the assembly binding issue biting us because there's actually a version of System.IdentityModel.Tokens.Jwt (5.1.<something>) already loaded into the process, it's just not the 5.2.0.0 bot framework is looking for. I'm going to go talk to @brandonh-msft about it shortly because he might have some thoughts on this and will follow up here in a little bit.

[brandonh-msft]

Yes the header name wasn't right; that had been resolved in all my deployments to Azure and still wasn't able to chat w/ the bot.

The assembly resolution problems are well known by the fxns team and, due in part to these issues, a v1-based func isn't possible because they have a hard ref (==) to Newtonsoft.Json 9.0.1 whereas botbuilder wants 10.0.3+

I have an idea on something that _might_ solve this which I'm giving a shot now.

[brandonh-msft]

No dice. Appears putting Bots on Azure Functions is blocked by https://github.com/Azure/azure-functions-host/issues/992 as well.

IMO fine to close this issue but up to the team.

[jorupp]

re: doing something like assembly bindings on Azure functions, you can try hooking the AssemblyResolve event as described in https://github.com/Azure/azure-functions-host/issues/992#issuecomment-298624059.

That approach has worked for the bot I have deployed as a v1 Azure Function.

[devedse]

So I just ran the bot local again without any AppId / password filled in (is this what you mean with no credentials?):

But I keep getting this error:

However when I deploy the application to Azure it does in fact work (using ngrok). Your bot also works fine when connecting to it (also using ngrok).

Also when I try to connect to the bot using a Bot project in Azure and test it using the Web Chat it keeps saying that it can't send the messages. Is this because of authentication that is enabled? And if so, can you disable it for the test web chat in azure?

[devedse]

@brandonh-msft is it still the case that the framework v4 does not support authentication? I saw that that the Microsoft/botbuilder pages were all updated with information about the botbuilder v4 preview?

[brandonh-msft]

@drub0y is closer to the work that would be necessary to fix this problem than I am. Any update we know of, Drew?

cc @cleemullins, @tomlm

[drub0y]

All auth scenarios should work at this point _using the latest framework bits from the repo_. We just did some direct work on the security token validation path a week or so again in fact and validated several of these scenarios.

@devedse, I just want to make sure I'm on the same page here: this thread was originally about hosting in Azure Functions... is that still the scenario you're working with? If so, I believe that this is still going to be an issue due to https://github.com/Azure/azure-functions-host/issues/992.

[devedse]

@drub0y ,

Good to hear that all Auth Scenario's should now work. Initially we were working on implementing the bot with Azure Functions, but have found on multiple places that Azure Functions are giving more issues then solutions when working with Bots. E.g. Skype Voice calling doesn't work, the binding redirects you're refering to, long startup times etc.

[brandonh-msft]

@devedse
it'd be great if you could post on the binding redirects issue in the Functions repo so we get another signal.

on the topic of long startup times, a couple of things:

1. You can always deploy a Function to a proper App Service and set it to 'Always On'
2. If going Functions to stay on Consumption billing, keep in mind if you run a Function 24/7 constantly, you may in fact be better off as an App Service from a cost perspective.
3. More details on what you're seeing would be great for me to take to the product team and keep an eye on internally

[gabog]

Closing as part of R10 triage. This now works with composer