Bot publishing fails to include ProjectReferenced DLLs in Adaptive Runtime

[thomas-chung]

Describe the bug

The bot publishing pipeline copies the csproj into a private directory in AppData/Roaming before running dotnet publish.

The problem with this approach is that if the csproj file has a ProjectReference with relative path, the dotnet publish would not be able to pick up the ProjectReference since these references are not copied over. Thus the deployed app would be missing dependencies on production (despite it running perfectly fine locally).

In effect, this would mean any bot developer who wants to include a Project Reference in their csproj would not be able to deploy their application even if true is set to true.

NOTE - this doesn't impact csproj/botproj where the dependency is in the form of that is because dotnet publish can resolve that from the source regardless of its location in the filesystem.

Version

Browser

• Electron distribution
• Chrome
• Safari
• Firefox
• Edge

OS

• macOS
• Windows
• Ubuntu

To Reproduce

Steps to reproduce the behavior:

1. Update in the Adaptive Runtime csproj to include to another project
2. Publish it
3. Call the bot from Emulator
4. Bot fails to be called because the service keeps returning 500 Internal Server Error

Expected behavior

Bot starts and works.

Screenshots

Additional context

[clearab]

I think the issue here is a bit more fundamental - the copy/paste creates uncertainty on what is getting deploy (things that were copied somewhere else) versus what I as the bot developer believe is the source of truth for my bot (the files I'm putting in source control from on disk). I think ideally we should be doing the build in-place, and I can easily find the build drops in my /bin folder as expected. Any alterations to the files as part of the Composer build process should also been done in-place, so I can do a diff and check them into source control.

[cwhitten]

Having all runtimes auto-ejected into the project relaxes the constraints we are working with when building the project. I agree that a /dist-like directory would suffice in the project. I wouldn't think this should be checked-in though.

A scenario that was considered in the current approach was the ability to rollback or rollfoward publishes. Even still, we can achieve a better solution for this scenario with a deeper git integration that utilizes the git protocol to achieve these types of operations while still building in place.

[benbrown]

I did a first pass at this -- As expected, simply not moving the project resolves the issue. @thomas-chung was kind enough to verify that much.

Since dotnet create a build folder of its own, and we write the "ready to deploy" settings in that build folder, this is all that is necessary.

HOWEVER, since JS does NOT create a separate build artifact, an additional step is required to write the "ready to deploy" settings into the build artifact WITHOUT modifying the source project itself. I will make this additional change tomorrow.

[benbrown]

The resolution here turned out to be simple:

• rather than modify the source appsettings.json, exclude it completely from the zip being deployed
• write the modified appsettings.json file directly to the zip file