Adaptive Bot: Opening the VS project for a newly created bot and launching doesn't result in a working bot

[darrenj]

Describe the bug

Created a new empty bot, added AppId/Secret (via Composer config) and selected LUIS key within Composer. Bot works fine inside WebChat/Emulator.

Opened VS project (.sln) which was scaffolded on disk. Click start debug and got a HTTP 500 as MicrosoftAppPassword wasn't present in the appSettings.config throwing secret errors on startup. Manually fixed this and then got "" is not a valid LUIS subscription key. as this is also missing

Version

1.4.0-nightly.237504

Browser

• [x] Electron distribution
• [ ] Chrome
• [ ] Safari
• [ ] Firefox
• [ ] Edge

OS

• [ ] macOS
• [x] Windows
• [ ] Ubuntu

To Reproduce

Steps to reproduce the behavior:

1. Create new bot based on empty template
2. choose luis key
3. add appid/secret
4. test
5. open VS solution in VS and observe runtime issues

Expected behavior

A bot should "just work" when opening in Visual Studio in just the same way as it does when testing locally in Composer

[peterinnesmsft]

@darrenj this is a known issue and out of scope for R13. There are a number of build steps that are currently executed within Composer natively. As things stand, it is not possible to execute a simple build and run of the app in Visual Studio, as these steps need to be made available in a way that can be executed by the underlying build system, whether it be .NET, Node.js, etc. We want to ensure we can do so without duplicating the same logic performed today ideally.

We discussed with Scott, Chris W, Andrew and other relevant folks across the engineering team a few weeks back on this, and the agreement was that we would revisit this post-R13.

Moving to backlog for now.

[darrenj]

I'm not quite so sure this is a feature-request, the previous runtime worked as expected in this area so this is a regression from where we were before? I believe the approach @benbrown and team before did was to have some form of ..\generated reference for the assets (he'll remember the details better than me).

This will block code-extensibility debugging for developers?

[peterinnesmsft]

We still reference the generated directory, which in this particular instance would be expected to contain the necessary LUIS application IDs that are utilized during recognition - that has not changed. However, as Composer is the one which creates this folder, the bot needs to be built and run through Composer first before the user can go to VS and make code changes.

Running dotnet build will regenerate dlls and copy the contents of the generated folder to the bin directory as-is. If the contents of that folder need to be regenerated, the user will need to go back to Composer to run its build process, which applies custom logic on top of the base dotnet build to create the contents of the generated folder.

Users should not be blocked, but it is a lot of back and forth. It is not the ideal flow in the slightest, but this goes back to my previous point that the custom build actions that Composer currently performs need to be separated out and made available in such a way that the same logic can be consistently performed directly through VS or any other context. It is a non-trivial amount of work which ultimately we deemed we would not have time to address in R13, but I don't believe this to be a regression from the story we have had up until now.

[sgellock]

I think this is a post R13 issue. If we feel this electrocutes people, let's discuss.

[tracyboehrer]

Also... appsettings just isn't populated with everything. When publishing it is, based on the profile. But for local dev, the developer would need to create a dev version of appsettings (which should work now). But that still requires an additional step.

[sgellock]

@darrenj milestone R14 my good man. you want to do the honors of moving it?

[darrenj]

Any volunteers for some documentation steps so developers can at least work around this ahead of R14?

[tracyboehrer]

The high level steps are:

• Only start the bot from Composer to be safe (for reason Peter listed above about the generated issue)
• Only edit appsetting.json from Composer: Project Settings -> Advanced (because bug https://github.com/microsoft/BotFramework-Composer/issues/7211#issuecomment-826542894)
• Create an appsettings.development.json in the Settings folder that contains the required settings for app id, app password, and optionally LUIS, storage, etc...

[tracyboehrer]

We should probably include, or link to, how to debug a local bot via ngrok. Deploying to Azure is time consuming.