liteiop.blogg.se - Visual studio 2019 remote development

#Visual studio 2019 remote development update#
#Visual studio 2019 remote development code#

Notice the entrypiont is tail -f /dev/null.

The entrypoint is not your application.

You can override this by updating launchSettings.json (see below). The Container Tools put the ASPNETCORE_ENVIRONMENT=Development thing in there.

The default environment is Development.

It could change later, but don’t be fooled. Even if you only have VS 2019, it’s still this path. The path to the remote debugger you see is C:\Users\yourname\vsdbg\vs2017u5 but this isn’t part of a VS 2017 install.

The remote debugger isn’t associated with a VS 2017 install.

VPNs and firewalls can really mess this up by blocking the SMB port.

#Visual studio 2019 remote development code#

You have to allow the drive with your source code to be mounted. You’ll get a warning that pops up if you don’t have volume sharing enabled in Docker. There’s a remote debugger your application code/source user secrets your local NuGet package cache and your local installation of fallback packages. There are some interesting things to note here: The container will continue to run until VS shuts down.ĭocker run -dt -v "C:\Users\yourname\vsdbg\vs2017u5:/remote_debugger:rw" -v "C:\src\solution\project:/app" -v "C:\Users\yourname\AppData\Roaming\Microsoft\UserSecrets:/root/.microsoft/usersecrets:ro" -v "C:\Users\yourname\.nuget\packages\:/root/.nuget/fallbackpackages2" -v "C:\Program Files\dotnet\sdk\NuGetFallbackFolder:/root/.nuget/fallbackpackages" -e "DOTNET_USE_POLLING_FILE_WATCHER=1" -e "ASPNETCORE_ENVIRONMENT=Development" -e "NUGET_PACKAGES=/root/.nuget/fallbackpackages2" -e "NUGET_FALLBACK_PACKAGES=/root/.nuget/fallbackpackages /root/.nuget/fallbackpackages2" -p 58260:80 -entrypoint tail project:dev -f /dev/null Even if you don’t actually start a debug setting, the container will be pulled, built, and run in the background. In Visual Studio the container for debugging will get built and will start as soon as you select the Docker configuration for running. (You can change this using in your project - see below.) VS Controls Container Startup and Teardown The -target base is the key - it’s not going to build the rest. When VS builds the container, you can see in the Container Tools output window it’s running a command like this:ĭocker build -f "C:\src\solution\project\Dockerfile" -t project:dev -target base -label "-by=visual-studio" "C:\src\solution" It’s not necessarily base that’s a magic target - it’s “the first stage found in the Dockerfile.”

#Visual studio 2019 remote development update#

UPDATE August 16, 2019: Microsoft has some documentation now on how Container Tools builds Dockerfiles.

This is helpful if you don’t already have a Dockerfile, but if you’re really just trying to get debugging working with VS, you only need the base container. The Dockerfile that gets generated has a bunch of named intermediate containers in it - base, build, publish. If you’re all Docker Compose up in there, this may or may not be helpful to you. I’m primarily using the single-container support - not the Docker Compose multi-container support. I ran into a bunch of trouble getting some things working the other day which caused me to dive a little deeper into how this works and I found a few interesting things. It’s a cool way to see how your app will behave in the container environment with the flexibility of edit-and-refresh functionality that doesn’t require the overhead of rebuilding the container each time. Container Tools in Visual Studio offers the ability to develop an application and have it run inside a container while Visual Studio debugs it on your host machine.