2

Title says it all - I have a brand new C#/.NET Bot Framework project (Basic bot template), downloaded from the Build pane of a new Azure Web App bot, that when I try to debug locally on my Surface Pro 4 with VS 2017, it consistently throws HTTP Error 403.14 when opening http://localhost:3984/ in either Chrome or Edge. No other clues, other than that. Local Bot Framework emulator (v3 and v4 preview) unable to connect - just 404's out.

enter image description here

Typical general debugging things not helping - e.g. deleting bin/obj/packages, clearing out .vs folder, etc.

Typical IIS Express debugging not helping - e.g. things like this:

Tried creating a new ASP.NET MVC project - running it locally in IIS Express works fine. No issues.

Note that for my Bot solution there is a default document configured (per the downloaded Azure Web App Bot solution):

<system.webServer>
    <defaultDocument>
      <files>
        <clear />
        <add value="default.htm" />
      </files>
    </defaultDocument>

Note I'm not even able to get a breakpoint in WebApiApplication.Application_Start() to fire:

enter image description here

That breakpoint is never reached. Pretty perplexed at this point - any ideas?

Just in case this is relevant - package versions:

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="Autofac" version="3.5.2" targetFramework="net46" />
  <package id="Chronic.Signed" version="0.3.2" targetFramework="net46" />
  <package id="EntityFramework" version="6.1.3" targetFramework="net46" />
  <package id="Microsoft.AspNet.WebApi" version="5.2.3" targetFramework="net46" />
  <package id="Microsoft.AspNet.WebApi.Client" version="5.2.3" targetFramework="net46" />
  <package id="Microsoft.AspNet.WebApi.Core" version="5.2.3" targetFramework="net46" />
  <package id="Microsoft.AspNet.WebApi.WebHost" version="5.2.3" targetFramework="net46" />
  <package id="Microsoft.Azure.DocumentDB" version="1.22.0" targetFramework="net46" />
  <package id="Microsoft.Azure.KeyVault.Core" version="1.0.0" targetFramework="net46" />
  <package id="Microsoft.Bot.Builder" version="3.15.2.2" targetFramework="net46" />
  <package id="Microsoft.Bot.Builder.Azure" version="3.15.2.2" targetFramework="net46" />
  <package id="Microsoft.Bot.Builder.History" version="3.15.2.2" targetFramework="net46" />
  <package id="Microsoft.Bot.Connector" version="3.15.2.2" targetFramework="net46" />
  <package id="Microsoft.CodeDom.Providers.DotNetCompilerPlatform" version="1.0.1" targetFramework="net46" />
  <package id="Microsoft.Data.Edm" version="5.7.0" targetFramework="net46" />
  <package id="Microsoft.Data.OData" version="5.7.0" targetFramework="net46" />
  <package id="Microsoft.Data.Services.Client" version="5.7.0" targetFramework="net46" />
  <package id="Microsoft.IdentityModel.Logging" version="1.1.4" targetFramework="net46" />
  <package id="Microsoft.IdentityModel.Protocol.Extensions" version="1.0.4.403061554" targetFramework="net46" />
  <package id="Microsoft.IdentityModel.Protocols" version="2.1.4" targetFramework="net46" />
  <package id="Microsoft.IdentityModel.Protocols.OpenIdConnect" version="2.1.4" targetFramework="net46" />
  <package id="Microsoft.IdentityModel.Tokens" version="5.1.4" targetFramework="net46" />
  <package id="Microsoft.Net.Compilers" version="1.2.1" targetFramework="net46" developmentDependency="true" />
  <package id="Microsoft.Rest.ClientRuntime" version="2.3.2" targetFramework="net46" />
  <package id="Microsoft.WindowsAzure.ConfigurationManager" version="3.2.1" targetFramework="net46" />
  <package id="Newtonsoft.Json" version="9.0.1" targetFramework="net46" />
  <package id="System.IdentityModel.Tokens.Jwt" version="5.1.4" targetFramework="net46" />
  <package id="System.Spatial" version="5.7.0" targetFramework="net46" />
  <package id="WindowsAzure.Storage" version="7.2.1" targetFramework="net46" />
</packages>

I have tried upgrading to the latest versions for each of those packages, but unfortunately results in the dreaded 'Microsoft.Net.Compilers package cannot be restored' error, so I've held off on going too far down that path.

SMshrimant
  • 638
  • 9
  • 15
Rob
  • 25,984
  • 32
  • 109
  • 155
  • Please check if a default document is configured and that the file exists. *Note: in bot application, it uses `default.htm` as default document*. – Fei Han Jul 31 '18 at 07:54
  • @Fei Han Yes, it exists. – Rob Jul 31 '18 at 12:32
  • And it is configured properly (as far as I can tell, per the above update to my question). – Rob Aug 03 '18 at 16:18
  • Hi @Rob, would you be willing to share your codebase with me? I'd like to help you out if I can. This actually sounds like it might be a VS issue but let's take a look. My GH handle is corinagum if you'd like to keep it private. – Corina Aug 03 '18 at 18:09
  • @Corina I'm in the process of updating VS 2017 to see if that helps. I stripped down + anonymized my bot solution, and in the process of doing so happened to copy it to my Windows desktop. There, it works just fine. So I then tried moving the full/non-anonymized version to my desktop - and it worked - once. Only once - as soon as I went to debug it again, it was instantly back to 403/404'ing. It's extremely confusing. Worse, the anonymized version of my repo works fine. The only difference is that I removed a few dialogs, which since they never would run, seem like they aren't the issue. – Rob Aug 03 '18 at 20:45
  • @Corina - pt 2 - let me try and get a version of the anonymized bot to fail, and I'll share that with you. In the meantime, can you think of any reason why directory-hopping & moving my solution around my file system seems to let it run (at least once)? Maybe a Windows Firewall thing? I've checked into that and everything seems pretty normal, so I can't think of what would be actively blocking IIS Express - plus, since a standard ASP.NET MVC solution works just fine from VS 2017 in IIS Express, it doesn't seem like it's an IIS Express issue. Sadly, I'm out of good ideas here :( – Rob Aug 03 '18 at 20:48
  • @Rob, some things to try if you haven't already... Have you tried changing the Port# and seeing if that works? Also, in your browser, you can try going to localhost:PORT/api/messages, which should give you a different error message.Just FYI, bots are actually ASP.NET Web API apps, not MVC projects so you might want to try making one of those. Finally, have you tried creating the virtual directory manually in the Web tab settings of Project properties? – Corina Aug 03 '18 at 21:01
  • @Corina - thank you for responding & so fast, it's much appreciated. Tried changing ports and unfortunately that did not help. I did try creating seperate WebAPI, MVC, and stock ASP.NET solutions to cover my bases - they all worked with no issues/403s/404s.. I did try creating the virtual directory manually in the Web tab - unfortunately that did not help. – Rob Aug 03 '18 at 21:05
  • @Rob, Darn.... Okay let me keep brainstorming and get back to you. – Corina Aug 03 '18 at 21:06
  • @Rob quick question, have you already tried making a separate, out of the box echo bot without modifying any code? – Corina Aug 03 '18 at 21:14
  • @Corina - yes - and that works. That was the base for my bot, to which I added a few dialogs and added to a Git repo for continuous delivery. Somehow that has rendered my main solution broken when running locally (publishes and runs fine in Azure). – Rob Aug 03 '18 at 21:16
  • @Rob was this bot created through Azure, or did you create it locally? Were you able to deploy before getting the 403/404s? Btw you can go ahead and share your anonymized code with me, even if it's working - might shed some light. – Corina Aug 03 '18 at 21:24
  • Let us [continue this discussion in chat](https://chat.stackoverflow.com/rooms/177383/discussion-between-corina-and-rob). – Corina Aug 03 '18 at 21:37
  • Hi, did you solve this problem? My bot hosted on Azure occasionally gives me this error which is quite annoying considering we are about to go to production. I would like to know whether there is a permanent solution or we can just fold the project and declare the framework not mature enough – Masinde Muliro Aug 24 '18 at 07:16
  • @Masinde Muliro - unfortunately, no solution yet for my particular local debugging scenario. I haven’t personally seen the same issue when deployed to Azure, though. – Rob Aug 24 '18 at 11:10

1 Answers1

0

Could you please cross check your filename.bot file with below code.

{
    "name": "final",
    "description": "",
    "secretKey": "",
    "services": [
        {
            "appId": "",
            "id": "xxxxx-xx-xx-xxx-xxxxx",
            "type": "endpoint",
            "appPassword": "",
            "endpoint": "http://localhost:3978/api/messages",
            "name": "http://localhost:3978/api/messages"
        }
    ]
}

(make sure you mention http for endpoint and name)

SMshrimant
  • 638
  • 9
  • 15
  • That file checks out, everything in it is correct. The Bot emulator is only part of the problem - the more fundamental problem I’m trying to solve is why the web app that *is* the Bot keeps 403’ing when you visit http://localhost:3984/ in a browser. Something is broken in the web app VS solution itself, and that is what I’m looking to understand and fix. – Rob Jul 30 '18 at 11:38
  • Did you try above thing? If yes, did it worked ? Is there another service running on the port `3984`? Could you try to `killall -15 node` because, `kill -15` gives process a chance to cleanup itself. You can also verify by `ps aux | grep node` – SMshrimant Aug 02 '18 at 19:11
  • Unfortunately, no, that did not work. No other service running on/process occupying that port. – Rob Aug 03 '18 at 13:44
  • This is also not a Node bot - it's C#. – Rob Aug 03 '18 at 15:44