${auto-detect-url} no longer works correctly when applicationUrl contains wildcard binding

[rjgotten]

Environment data

dotnet --info output:

.NET Core SDK (reflecting any global.json):
 Version:   2.1.400
 Commit:    8642e60a0f

Runtime Environment:
 OS Name:     Windows
 OS Version:  10.0.16299
 OS Platform: Windows
 RID:         win10-x64
 Base Path:   C:\Program Files\dotnet\sdk\2.1.400\

Host (useful for support):
  Version: 2.1.2
  Commit:  811c3ce6c0

VS Code version: 1.27.1
C# Extension version: 1.16.1

Steps to reproduce

Create a launchSettings.json which uses a wildcard applicationUrl, e.g.

{
  "profiles": {
    "MyProject": {
      "commandName": "Project",
      "commandLineArgs": "startWeb",
      "launchBrowser": true,
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "http://*:8095/"
    }
  }
}

Create a launch.json which uses ${auto-detect-url} in its launchBrowser section, e.g.

 "launchBrowser": {
  "enabled": true,
  "args": "${auto-detect-url}",
  "windows": {
    "command": "cmd.exe",
    "args": "/C start ${auto-detect-url}"
  },
  "osx": {
    "command": "open"
  },
  "linux": {
    "command": "xdg-open"
  }
}

Expected behavior

When web project is launched, browser is opened on localhost, e.g. localhost:8095, as has been the case in past versions of VSCode and the C# extension.

Actual behavior

Browser is opened with zero IPv6 address, e.g. [::]:8095, instead.

[gregg-miskelly]

@rjgotten Thanks for reporting this!

This may be obvious, but just in case - you can sort of work around this by either --

1: changing applicationUrl to use 'localhost' (or your computer name, or whatever you like)
-or-
2: change launch.json to hard code the correct URL

This broke in 1.16 because this extension used to ignore applicationUrl. But if you had configured the URL to use a '*' hostname in the ways that this extension did support (ex: environment variable, code) I believe you would have had the same problem.

[rjgotten]

this extension used to ignore applicationUrl.

Ah. That kind of explains it.

Yes, we know about the localhost workaround, but it doesn't quite work when you have to debug web-apps on a device and can't bridge localhost; while you also have to have a configuration that should work on any developer's local workstation.

Right now we're re-configuring with localhost and require those that need to test on devices, to temporarily update the configuration and not commit that change. Not ideal, you can imagine.

[rjgotten]

Oops... mistakingly closed the issue with that last comment. That was not intended.

[gregg-miskelly]

@rjgotten: In case this is useful to you, you can effectively get back to the old behavior (where applicationUrl was ignored) by, in launch.json, add something like this. launch.json takes precedence over launchSettings.json.

            "env": {
                "ASPNETCORE_URLS":"http://localhost:4000"
            }

[rjgotten]

@gregg-miskelly
Will share that with the development team for the project that is hitting this particular bump in the road.
Thanks. 👍