Visual studio can create a project from template with "enable Docker support". In which a section in launchSettings.json is created with
"Docker": {
"commandName": "Docker",
"publishAllPorts": true
}
When started with this configuration, what I see is that docker image is built and started in Docker Desktop and debugging is started in a remote debugging fashion (I see no dotnet instance started locally)
My question:
Are my assumptions correct?
Is there any documentation that describe thoese behaviour and where we can tweak these settings, such as targeting a remote docker host?
Related
How can I debug while using --host option on Vue 3 Vite so I can debug my phone instance for example. At the moment Im using visual studio code plugin "Vite"
launch.json:
{
"version": "0.2.0",
"configurations": [
{
"type": "pwa-chrome",
"request": "launch",
"name": "Launch Chrome against localhost",
"url": "http://localhost:4000",
"webRoot": "${workspaceFolder}/app",
}
]
}
package.json
"scripts": {
"dev": "vite --host --port 4000",
}
Vite config options
with this I'm being able to run on lan and debug but only on my pc, if I try from my phone or other pc, it connects but it wont stop on any breakpoint.
In order to debug any web app, web browser running on your phone must support a debugging protocol. Chrome for Android for example does support what you need, see Remote debugging article.
As for another PC, you need to launch Chrome there with a remote debugging command line switch as well, and then edit your launch.json to attach your vs code instance to different host (ip and port). That is of course if you want to be able to set breakpoints in vs code on your developer machine and then reflect that on another PC.
Roughly saying, you need to point your vs code to a running target
browser, for example, in your current config vs code launches instance of Chrome with a debugging switch enabled for you, behind the scenes
To be able to run Linux containers on a Windows 2016 host we followed this tutorial. The issue we're having is that we can't seem to enable the experimental features. In the docs it says:
To enable experimental features in the Docker CLI, edit the config.json file and set experimental to enabled.
File C:\ProgramData\docker\config\config.json:
{
"experimental": "enabled",
"debug": true
}
After restarting the Docker service (Restart-Service docker) and running docker info we sill see the flag Experimental: false:
Operating System: Windows Server 2016 Standard Version 1607 (OS Build 14393.3686)
OSType: windows
Architecture: x86_64
Docker Root Dir: C:\ProgramData\docker
Experimental: false
How is it possible to enable the Docker experimental features on a Windows Server 2016?
Even when I try set the environment variable and restart powershell and the docker service it doesn't register within docker info:
[Environment]::SetEnvironmentVariable("DOCKER_CLI_EXPERIMENTAL", "enabled", "Machine")
After logging in to docker with docker login the file "C:\Users\bob\.docker\config.json". When adding the key it's still not registered after service restart:
{
"auths": {
"https://index.docker.io/v1/": {
"auth": "xxxxx"
}
},
"HttpHeaders": {
"User-Agent": "Docker-Client/19.03.5 (windows)"
},
"experimental": "enabled",
"debug": true
}
You put your configuration to a file with name config.json. But according to docs correct file name is daemon.json.
Full path to config file must be: C:\ProgramData\docker\config\daemon.json
From all of the answers above, only adding --experimental parameter in services -> docker -> Path to executable worked. You can change it using regedit.exe
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\docker
key ImagePath value "C:\Program Files\docker\dockerd.exe" --experimental --run-service if you have any other starting parameters you should keep them.
You can do it using sc (in powershell sc.exe)
I followed the Canonical tutorial for linux containers on Windows, and got stuck trying to pull the correct ubuntu (linux not windows) image (then found your question about setting experimental). If you ask the dockerd.exe for parameters it will accept (dockerd.exe --help) one of the options is --experimental.
Setting --experimental on the dockerd invocation worked for me.
If you can configure the invocation of your daemon with --experimental (rather than inside a configuration file), this could solve your problem.
Try setting the environment variable with:
[Environment]::SetEnvironmentVariable("DOCKER_CLI_EXPERIMENTAL", "enabled")
This worked on my linux cluster where specifying User or Machine seemed to result in the variable being ignored..
I found out that it simply won't run on Windows Server 2016 as stated here:
Docker Desktop has changed its way to leverage WSL2 for running Linux containers on Windows 10. The plan for Docker EE is unclear as Docker Inc. has sold it to Mirantis. https://github.com/docker/for-win/issues/6470#issuecomment-633883063
So if you plan to run both Linux and Windows containers in production, you may want to look for other options, such as Kubernetes.
It turns out the Linux Containers on Windows (lcow) Server is a preview feature of both Windows Server, version 1709 and Docker EE. It won’t work on Windows Server 2016 of which the version is older than 1709.
I created the sample dotnet webapi project via dotnet new webapi (v3.1.101) and updated launchSettings.json's applicationUrl to first http:*:5000 then to http:0.0.0.0:5000. When I try to go to http://<MY_COMPUTER_NETWORK_NAME>:5000/WeatherForecast, it times out, yet when I locally try http://localhost:5000/WeatherForecast, it works.
I ran a React App on port 5000 and I could successfully connect to it remotely, so I don't think it is a firewall issue.
I am running on a Mac. I also tried adding .UseUrls(...) without success.
Why can't I connect remotely?
Thanks in advance!
dotnet run will try to automatically load MyApplication\Properties\launchSettings.json.
If file launchSettings.json exists and "all addresses" binding is set:
{
"profiles": {
"Uno": {
"commandName": "Project",
"launchBrowser": true,
"applicationUrl": "https://0.0.0.0:5001;http://0.0.0.0:5000",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
}
}
Then running the application should give this result:
> dotnet run
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://0.0.0.0:5001
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://0.0.0.0:5000
and checking open ports:
> netstat -na | ? { $_ -match "5000|5001" }
TCP 0.0.0.0:5000 0.0.0.0:0 LISTENING
TCP 0.0.0.0:5001 0.0.0.0:0 LISTENING
If launchSettings.json does not exist or exist with different name, default binding will apply:
> mv .\Properties\launchSettings.json .\Properties\launch.json
> dotnet run
info: Microsoft.Hosting.Lifetime[0]
Now listening on: http://localhost:5000
info: Microsoft.Hosting.Lifetime[0]
Now listening on: https://localhost:5001
unless you specify the urls using specific option:
server.urls="http://0.0.0.0:5000;https://0.0.0.0:5001"
Also note that the first time that any application tries to bind to 0.0.0.0:port, a window like this appears:
It is very easy to miss it if you are in multi monitor setup or if you immediately focus on other windows. Also, this dialog will set an application specific firewall rule, so maybe you created the rule for the React application and not the rule for the dotnet app.
I'm using VSCode in Windows and I've noticed I cannot use the dotnet run command from the terminal, I have to hit play from the Debug sidebar window for it to work, and then I can connect from other computers on the same network.
If you would like to launch with the terminal, then I think you have to manually specify your launch.json file in the options. See the --launch-profile option here: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-run
I run a process inside a docker container that needs to be debugged. The process is started in the docker's entry point via
dlv debug /go/src/path/to/package --headless --listen=:2345 --log for the purpose of enabling debugging later in VSCode.
The docker container is started via
docker run --rm -it -p 2345:2345 my_image:tag. Note delve's port is exposed.
In VSCode I define launch.json as follows:
{
"version": "0.2.0",
"configurations": [
{
"name": "Attach remote",
"type": "go",
"request": "attach",
"mode": "remote",
"port": 2345,
"host": "127.0.0.1",
"apiVersion": 1
}
]
}
Upon starting the "attach remote" VSCode debugging configuration I get
It isn't crystal clear, but that UI leads me to believe I'm now connected to the remote headless debugger and ready to debug. I have one breakpoint defined which I know would be hit by a request I can send the remote process. I send that request, I get a result, and that breakpoint never hit, indicating that I haven't yet achieved remote debugging.
Is something wrong with my VSCode "attach remote" configuration? I can do command-line debugging with dlv connect :2345 and actually debug the remote process just fine, which indicates the headless server is functional. I would rather debug with source code, in VSCode though.
Try again with the latest beta of vscode-go (April 2020) (for any time after April 2020, the latest official vscode-go release will be enough)
Microsoft/vscode-go issue 2010 includes this confirmation from Ramya Rao:
The fix from #3108 is available in the latest beta version of this extension. Please do try and share feedback
The latest version of the extension now has the fix to this issue
And:
I can confirm that I am able to hit breakpoints now using AWS SAM to launch a linux container with delve and go binaries compiled from Windows.
For anyone still having this problem (like I was before I edited this comment), take care that the "remotePath" element of your launch.json is the absolute path to the source files as compiled on your local system (not the container).
As implied above - it's the absolute local path that is added to the DWARF compilation unit file table when you compile the binary.
I am developing an ASP.NET Core Web API in Visual Studio and using Postman to test it.
To do so, I start the integrated IIS Express Server via clicking on the "Run" Button in Visual Studio. I would expect the server always listening on the same port but on every start it is assigned a different port. How can I change this?
This is my output of the ASP.NET Core Web Server in Visual Studio after I started and stopped the server 3 times:
WebApi> Hosting environment: Development
WebApi> Content root path: C:\Code\Work\webcoreapi\WebApi
WebApi> Now listening on: http://localhost:25626
WebApi> Application started. Press Ctrl+C to shut down.
WebApi> Hosting environment: Development
WebApi> Content root path: C:\Code\Work\webcoreapi\WebApi
WebApi> Now listening on: http://localhost:22130
WebApi> Application started. Press Ctrl+C to shut down.
WebApi> Hosting environment: Development
WebApi> Content root path: C:\Code\Work\webcoreapi\WebApi
WebApi> Now listening on: http://localhost:22405
WebApi> Application started. Press Ctrl+C to shut down.
If I run the same Application in command line via dotnet run it starts the application and listens on localhost:5000 as expected every single time.
So it has to do something with my Visual Studio Configuration but I cannot find it. Here is my launchSettings.jsonfile:
{
"iisSettings": {
"windowsAuthentication": false,
"anonymousAuthentication": true,
"iisExpress": {
"applicationUrl": "http://localhost:5000/",
"sslPort": 0
}
},
"profiles": {
"IIS Express": {
"commandName": "IISExpress",
"launchUrl": "http://localhost:5000/",
"environmentVariables": {
"ASPNETCORE_ENVIRONMENT": "Development"
}
}
}
}
So I guess everything is correctly configurated. I know that Visual Studio tries to find an open port if the default one is not availability but I already checked that too. The port 5000 is always free to use when I start the server in VS.
Does anyone have a hint how to make VS always start on 5000?
I am using Visual Studio Community 2017 (Version 15.3.5)
Under properties in the startup project, look for launchSettings.json.
You can set the applicationURL value there.
I.e. http://localhost:5000
The environment variables and launch URL can be set there as well.