Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Standalone dev server can't determine whether to run in Debug or Release mode #5486

Closed
SteveSandersonMS opened this issue Mar 14, 2018 · 11 comments
Closed

Comments

@SteveSandersonMS
Copy link
Member

@SteveSandersonMS SteveSandersonMS commented Mar 14, 2018

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
Copy link
Member Author

@SteveSandersonMS SteveSandersonMS commented Mar 14, 2018

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!

SteveSandersonMS referenced this issue in dotnet/blazor Mar 14, 2018
@SteveSandersonMS SteveSandersonMS changed the title Standalone dev server can't run app in Release mode Standalone dev server can't determine whether to run in Debug or Release mode Mar 14, 2018
@torhovland
Copy link

@torhovland torhovland commented Apr 8, 2018

@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.

natemcmaster referenced this issue in dotnet/blazor Aug 7, 2018
…d #261
natemcmaster referenced this issue in dotnet/blazor Aug 7, 2018
…d #261
natemcmaster referenced this issue in dotnet/blazor Aug 7, 2018
…rkaround #261
natemcmaster referenced this issue in dotnet/blazor Aug 7, 2018
…d #261
natemcmaster referenced this issue in dotnet/blazor Aug 7, 2018
…rkaround #261
@kant2002
Copy link
Contributor

@kant2002 kant2002 commented Sep 1, 2018

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
Copy link
Member Author

@SteveSandersonMS SteveSandersonMS commented Sep 3, 2018

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
Copy link
Contributor

@kant2002 kant2002 commented Sep 3, 2018

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
Copy link
Contributor

@kant2002 kant2002 commented Nov 9, 2018

@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
Copy link
Member

@danroth27 danroth27 commented Nov 9, 2018

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

@aspnet-hello aspnet-hello transferred this issue from dotnet/blazor Dec 17, 2018
@aspnet-hello aspnet-hello added this to the Backlog milestone Dec 17, 2018
@geistchevalier
Copy link

@geistchevalier geistchevalier commented Dec 28, 2018

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
Copy link

@salaros salaros commented Feb 18, 2019

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
Copy link

@ransagy ransagy commented Mar 1, 2019

@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
Copy link
Contributor

@pranavkm pranavkm commented Jun 11, 2020

This has since been resolved.

@pranavkm pranavkm closed this Jun 11, 2020
@msftbot msftbot bot locked as resolved and limited conversation to collaborators Jul 11, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
10 participants