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

Add documentation about launchSettings.json, .csproj options, Dockerfile requirements #193

Open
tillig opened this issue Jun 18, 2019 · 4 comments

Comments

Projects
None yet
2 participants
@tillig
Copy link

commented Jun 18, 2019

When you right-click in the VS Solution Explorer and add Docker support to an ASP.NET Core project, it does a few things - you get a Dockerfile and you get a launchSettings.json entry, for example.

launchSettings.json ends up containing a bunch of things that aren't part of the launchSettings schema like httpPort, sslPort, and useSSL.

{
  "iisSettings": {
    "windowsAuthentication": false,
    "anonymousAuthentication": true,
    "iisExpress": {
      "applicationUrl": "https://localhost:44308",
      "sslPort": 44308
    }
  },
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "IIS Express (Development)": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "Kestrel (Development)": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "https://localhost:44308"
    },
    "Docker": {
      "commandName": "Docker",
      "launchBrowser": true,
      "launchUrl": "{Scheme}://{ServiceHost}:{ServicePort}/",
      "httpPort": 58260,
      "useSSL": false,
      "sslPort": 44308
    }
  }
}

There are also some magic strings in there - {Scheme}, for example. Other than the ones shown, are there others?

There things you can put in your .csproj file like <DockerDebuggeeArguments> that can affect how Docker starts up your container.

You can also add things like environmentVariables in launchSettings.json for the Docker configuration and those will get passed to the application but won't be global environment variables you can inspect in the running container.

The Dockerfile that gets generated has a bunch of named intermediate containers but it turns out you only need the one named base for the VS debugging to work.

There have been other issues (eg #62, #160) that have touched on some of this, but... it'd be nice if there was documentation covering the options available in launchSettings.json, .csproj files, and so on. It's really hard to figure this stuff out and ends up being a manual trek through .props and .targets files, decompilers on the libraries installed with VS, and slogging through issues and forums.

@bwateratmsft

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

Thanks @tillig. We agree on the need for documentation and are working on it.

@tillig

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

In the meantime, I blogged a lot of the stuff I've found whilst spelunking, in case that helps anyone.

@bwateratmsft

This comment has been minimized.

Copy link
Contributor

commented Jun 18, 2019

@tillig That guide is great! To address the mystery of how "dotnet" starts inside the container in debug mode--

  1. We launch VSDBG using that long-ish "docker exec" script, /bin/sh -c "ID=.; if....". The reason for this long script is to figure out within the container if it's Alpine or Debian/Ubuntu, because we use a different version of VSDBG depending on which.
  2. After VSDBG is launched, Visual Studio attaches to it and instructs it to launch the app itself, with "dotnet". It also passes in the environment variables from launchSettings.json. Having VSDBG launch the app means that you are attached to the process from the very beginning, and won't miss something going wrong in startup.
@tillig

This comment has been minimized.

Copy link
Author

commented Jun 18, 2019

That explains why I didn't see it in Process Monitor, then. Thanks! I tried to get execsnoop and auditd running to see if I could catch when it was starting up but gave up. This helps!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.