Aspnetcore: Standalone dev server can't determine whether to run in Debug or Release mode

[SteveSandersonMS]

Currently, the standalone dev server in Microsoft.AspNetCore.Blazor.Cli is hardcoded to look for app binaries in (sourceRoot)\bin\Debug. If you're launching from the command line, it isn't aware of any -c Release flag, and if you're launching from VS, it doesn't know which solution configuration you have enabled.

At the moment although I have an idea of how we could fix it for the command line, I'm not sure how we can make it aware of the active VS solution configuration.

The main limitation seems to be that we're using the Web SDK. If the standalone app didn't use the Web SDK and was instead more like a pure console app, then on startup the process working directory would be set to the client app's active bin\(Debug|Release)\(framework) directory, which would be ideal because then we'd know precisely which dist directory to serve. Unfortunately this doesn't work if you use the web SDK because VS always sets the working directory to the project root if you're using the Web SDK (https://github.com/dotnet/cli/issues/4473#issuecomment-256674279).

In the Web SDK source, there's a flag called EnableDefaultRunWorkingDirectory that you can set to false to cause the working directory to be the bin dir (i.e., bin\(Debug|Release)\(framework)). That would be perfect, except it seems that VS doesn't know about this flag and still uses the project root anyway.

Putting this on backlog because it's not an insane limitation that the dev server only supports Debug builds (after all, it is the dev server).

@BillHiebert Do you know:

• If there's any way to make VS launch web projects with the CWD set to the active bin folder instead of the project root directory?
• And if not, is there any way for a launched executable (set via <RunCommand>) to know which solution configuration is currently active?
• And if not, might it be possible to extend the VS tooling to respect the EnableDefaultRunWorkingDirectory flag in the future?

Thanks!

[SteveSandersonMS]

Update: I've made the dev server assert that only Debug or Release dir exists, and pick whichever one does. If you have both, it refuses to start (and says why). We still need a proper fix though!

[torhovland]

@SteveSandersonMS Checking that either Debug or Release exists wouldn't be so bad if Clean Solution in VS actually cleaned this properly. Unfortunately, even though files get deleted, the folders are left behind. It would be good if your check not only checked for the existence of the folders, but rather of non-empty folders.

[kant2002]

I may miss something, but why not simply use

<PropertyGroup Condition="$(Configuration) == 'Debug'">
    <RunArguments>blazor serve -c Debug</RunArguments>
  </PropertyGroup>
  <PropertyGroup Condition="$(Configuration) == 'Release'">
    <RunArguments>blazor serve -c Release</RunArguments>
  </PropertyGroup>

this is against spirit of new project style, but at least allow moving forward.

[SteveSandersonMS]

Interesting idea. I haven't tried it so can't be sure whether it would work. But if it does, maybe it could even be simplified further to:

<RunArguments>blazor serve -c $(Configuration)</RunArguments>

[kant2002]

I would propose this, but I'm not sure will it work with MSBuild or not. If you (@SteveSandersonMS) don't mind, I could try to implement this, to get myself comfortable with Blazor codebase.

[kant2002]

@danroth27 Given that PR is not suit your approach, yes. I do interesting in other options which is more aligned with your goals. From closing comment there mention about 'run arguments' is there some issue where discussion happens? I have some guesses, but would like to hold them before speculating.

[danroth27]

@rynowak Could you provide some direction on how we think this might work with launch settings?

[geistchevalier]

I would like to add that you may need to restart Visual Studio after removing the folders for the error to go away, I'm using VS2017 if that helps.

[salaros]

As a temporary workaround you could drop this Directory.Build.targets into your Blazor app's solution folder and auto-magically Release folder will be removed in Debug configuration and vice-versa.

[ransagy]

@salaros Thanks, that works well.
@SteveSandersonMS Maybe include something of that sort in the templates as a slightly-better temporary fix? or is there a proper way to handle this lined up somewhere?

[pranavkm]

This has since been resolved.