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

Support launchSettings.json defaults #2017

Closed
guidobouman opened this issue Feb 7, 2018 · 8 comments
Closed

Support launchSettings.json defaults #2017

guidobouman opened this issue Feb 7, 2018 · 8 comments

Comments

@guidobouman
Copy link

guidobouman commented Feb 7, 2018

Environment data

dotnet --info output:

.NET Command Line Tools (2.1.4)

Product Information:
 Version:            2.1.4
 Commit SHA-1 hash:  5e8add2190

Runtime Environment:
 OS Name:     Mac OS X
 OS Version:  10.13
 OS Platform: Darwin
 RID:         osx.10.12-x64
 Base Path:   /usr/local/share/dotnet/sdk/2.1.4/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.5
  Build    : 17373eb129b3b05aa18ece963f8795d65ef8ea54

VS Code version: 1.19.3
C# Extension version: 1.13.1

Steps to reproduce

  • Configure a dotnet core app
  • Set applicationUrl or ASPNETCORE_URLS in launchSettings.json
  • Launch project with dotnet run
  • See project running on the right URL + PORT
  • Start project in VSCode
  • See project running from default URL localhost:5000

Expected behavior

The settings in Properties/launchSettings.json are used as defaults for the projects in launch.json

Actual behavior

launchSettings.json is ignored.

Discussion

The dotnet cli has implemented this at it's core. But the debugger is unfortunately not taking this file into account. See the discussion / implementation at https://github.com/dotnet/cli/issues/6617 (@DustinCampbell is looped-in there as well.)

I'd be happy to create a PR when pointed into the right direction.

@gregg-miskelly
Copy link
Contributor

Sounds like a reasonable request. If I am reading the code in dotnet run correctly, it looks like here is most of the code we would need to borrow:

https://github.com/dotnet/cli/blob/master/src/dotnet/commands/dotnet-run/RunCommand.cs#L113
https://github.com/dotnet/cli/blob/master/src/dotnet/commands/dotnet-run/LaunchSettings/ProjectLaunchSettingsProvider.cs#L20

@guidobouman
Copy link
Author

Yeah, that looks like it.

Is there anything I can do to maybe help push it up to the 1.14 milestone?

@gregg-miskelly
Copy link
Contributor

1.14 will ship any day now. So only high priority bug fixes will go into that release.

@guidobouman
Copy link
Author

Ah, oops. 1.15 it is then.

@guidobouman
Copy link
Author

guidobouman commented May 1, 2018

Hey @gregg-miskelly, thanks for fixing this! Is see a fixed status, but 1.15 is still in beta. Any timeframe on when 1.15 is released?

Thanks for the hard work, I have a PR ready for our projects to simplify our configs. 🎉

@WolfspiritM
Copy link

WolfspiritM commented May 13, 2018

Maybe I'm doing something wrong but this does only work partly for me with 1.15.

My launchSettings.json looks like that:

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "http://localhost:61525/",
      "sslPort": 0
    }
  },
  "profiles": {
    "WebApplication2": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "api/values",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "http://localhost:61527/"
    }
  }
}

It still tries to bind to :5000 instead of 8100 as it should and does when using dotnet run.
If I add an environment Variable ASPNETCORE_URLS to the profiles.environemtVariables it works as expected.

Would it be possible to also support applicationurl as that's what VS uses when configuring the Port/URL?

@gregg-miskelly
Copy link
Contributor

@WolfspiritM Sure. At the time this feature request was made, the CLI didn't support applicationUrl but looks like they added it here. It looks fairly simple to add, so if you want to open an issue for it, I think we could add support in 1.16.

@WolfspiritM
Copy link

@gregg-miskelly Thanks. I thought it was supported as the Feature Request even contains applicationUrl under "Steps to reproduce". I created an issue for it: #2296

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

3 participants