microsoft / vscode-remote-try-dotnet Goto Github PK

.NET sample project for trying out Dev Containers

Home Page: https://aka.ms/vscode-remote/containers/getting-started

License: MIT License

C# 100.00%

vscode-remote-try-dotnet's Introduction

Try Out Development Containers: .NET

A development container is a running container with a well-defined tool/runtime stack and its prerequisites. You can try out development containers with GitHub Codespaces or Visual Studio Code Dev Containers.

This is a sample project that lets you try out either option in a few easy steps. We have a variety of other vscode-remote-try-* sample projects, too.

Note: If you already have a Codespace or dev container, you can jump to the Things to try section.

Setting up the development container

GitHub Codespaces

Follow these steps to open this sample in a Codespace:

Click the Code drop-down menu.
Click on the Codespaces tab.
Click Create codespace on main .

For more info, check out the GitHub documentation.

VS Code Dev Containers

If you already have VS Code and Docker installed, you can click the badge above or here to get started. Clicking these links will cause VS Code to automatically install the Dev Containers extension if needed, clone the source code into a container volume, and spin up a dev container for use.

Follow these steps to open this sample in a container using the VS Code Dev Containers extension:

If this is your first time using a development container, please ensure your system meets the pre-reqs (i.e. have Docker installed) in the getting started steps.
To use this repository, you can either open the repository in an isolated Docker volume:
- Press F1 and select the Dev Containers: Try a Sample... command.
- Choose the ".NET Core" sample, wait for the container to start, and try things out!
  
  Note: Under the hood, this will use the Dev Containers: Clone Repository in Container Volume... command to clone the source code in a Docker volume instead of the local filesystem. Volumes are the preferred mechanism for persisting container data.
Or open a locally cloned copy of the code:
- Clone this repository to your local filesystem.
- Press F1 and select the Dev Containers: Open Folder in Container... command.
- Select the cloned copy of this folder, wait for the container to start, and try things out!
If you want to enable HTTPS, see enabling HTTPS to reuse your local development cert in the container.

Things to try

Once you have this sample opened, you'll be able to work with it like you would locally.

Some things to try:

Restore Packages: When notified by the C# extension to install packages, click Restore to trigger the process from inside the container! You can also execute dotnet restore command in a terminal.
Edit:
- Open Program.cs
- Try adding some code and check out the language features.
- Make a spelling mistake and notice it is detected. The Code Spell Checker extension was automatically installed because it is referenced in .devcontainer/devcontainer.json.
- Also notice that the C# extension is installed. Tools are installed in the mcr.microsoft.com/devcontainers/dotnet image and Dev Container settings and metadata are automatically picked up from image labels.
Build, Run, and Debug:
- Open Program.cs
- Add a breakpoint (e.g. on line 16).
- Press F5 to launch the app in the container.
- Navigate to the weather endpoint, for example, http://localhost:5000/paris/weather.
- Once the breakpoint is hit, try hovering over variables, examining locals, and more.
- Continue (F5). You can connect to the server in the container by either:
  - Clicking on Open in Browser in the notification telling you: Your service running on port 5000 is available.
  - Clicking the globe icon in the 'Ports' view. The 'Ports' view gives you an organized table of your forwarded ports, and you can access it with the command Ports: Focus on Ports View.
- Notice port 5000 in the 'Ports' view is labeled "Hello Remote World." In devcontainer.json, you can set "portsAttributes", such as a label for your forwarded ports and the action to be taken when the port is autoforwarded.
Note: In Dev Containers, you can access your app at http://localhost:5000 in a local browser. But in a browser-based Codespace, you must click the link from the notification or the Ports view so that the service handles port forwarding in the browser and generates the correct URL.
Rebuild or update your container

You may want to make changes to your container, such as installing a different version of a software or forwarding a new port. You'll rebuild your container for your changes to take effect.

Open browser automatically: As an example change, let's update the portsAttributes in the .devcontainer/devcontainer.json file to open a browser when our port is automatically forwarded.
- Open the .devcontainer/devcontainer.json file.
- Modify the "onAutoForward" attribute in your portsAttributes from "notify" to "openBrowser".
- Press F1 and select the Dev Containers: Rebuild Container or Codespaces: Rebuild Container command so the modifications are picked up.
Install Node.js using a Dev Container Feature:
- Press F1 and select the Dev Containers: Configure Container Features... or Codespaces: Configure Container Features... command.
- Type "node" in the text box at the top.
- Check the check box next to "Node.js (via nvm) and yarn" (published by devcontainers)
- Click OK
- Press F1 and select the Dev Containers: Rebuild Container or Codespaces: Rebuild Container command so the modifications are picked up.

Contributing

This project welcomes contributions and suggestions. Most contributions require you to agree to a Contributor License Agreement (CLA) declaring that you have the right to, and actually do, grant us the rights to use your contribution. For details, visit https://cla.opensource.microsoft.com.

When you submit a pull request, a CLA bot will automatically determine whether you need to provide a CLA and decorate the PR appropriately (e.g., status check, comment). Simply follow the instructions provided by the bot. You will only need to do this once across all repos using our CLA.

This project has adopted the Microsoft Open Source Code of Conduct. For more information see the Code of Conduct FAQ or contact [email protected] with any additional questions or comments.

Trademarks

This project may contain trademarks or logos for projects, products, or services. Authorized use of Microsoft trademarks or logos is subject to and must follow Microsoft's Trademark & Brand Guidelines. Use of Microsoft trademarks or logos in modified versions of this project must not cause confusion or imply Microsoft sponsorship. Any use of third-party trademarks or logos are subject to those third-party's policies.

vscode-remote-try-dotnet's People

Contributors

Stargazers

Watchers

Forkers

jo-ninja blairham alexandre-tardif pietrobrunetti gl3nni3 riaann rirl jimcsg xzaero denglund bergmeister dwainew neyahpeterson klawrawkz roverjobs martinwoodward eljog shawnburke teja-nagoori fredrikhr cr-learning-repos sauliuse kopetan-ms bhaskers-blu-org2 alefragnani taffywrinkle claudiusgonzo molausson qiaorong-feng joannawu-wd runceel chaoyun8888 rorypreddygithubenterprise jmcd richross fara-nak cedricleblond anpaskin aditya30394 nina-wang-test jhoanf vso-dev2 superless codespaces-test-01 codespaces-test-02 recepdmr rodrmoya codespaces-test-08 dfdumaresq global-localhost global19 global19-atlassian-net rodrigovaras legomushroom olegk1980 ups216 rajkumar42 rachelguo76 emily-potyraj lorenpaulsen yuanlongli tangshimei qpc-database misterjimson gangganghao lixinyang123 vadi2 reza8i losolio acedya tiago-peres kprpg maremare chanhong ptzagk cplemm isabella232 kevinobee olguzzar alidinesa cmaneu bc89 jnsoft jorditudela sayedhafiz darkstone045 raxtor007 ajosephsen 01748873726 rsrobbins graymc namespaceconflict jsullivan1201 cs-util-com rockbanzai andyreinke ken-okabe harini-chitra vnza69 igecloudsdev

vscode-remote-try-dotnet's Issues

Debugging fails after first time

It looks like starting and stopping the debugger doesn't quite clean up, so when I try to debug a second time I get an error that the port is already in use.
If I start then stop the debugger, the app is still running on port 9000, so there's something that doesn't get stopped in the "debug container" when I stop the task in vscode.

viswa

"change"

练习

Unable to create a dotnet container via "Try a Sample"

Using Docker in WSL2:

[0 ms] Start: Resolving remote
[3 ms] Start: Check Docker is running
[3 ms] Start: Run: docker info
[406 ms] Start: Run: docker volume ls -q
[567 ms] Start: Run: docker volume create --label vsch.local.repository=https://github.com/Microsoft/vscode-remote-try-dotnetcore --label vsch.local.repository.unique=false vsc-remote-sample
[738 ms] Start: Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/Microsoft/vscode-remote-try-dotnetcore --filter label=vsch.local.repository.volume=vsc-remote-sample --filter label=vsch.local.repository.folder=vscode-remote-try-dotnetcore --filter label=vsch.quality=undefined
[922 ms] Start: Run: docker build -f c:\Users\Connor\.vscode-oss-dev\extensions\ms-vscode-remote.remote-containers-0.117.1\scripts\volumeBootstrap.Dockerfile -t vsc-volume-bootstrap c:\Users\Connor\.vscode-oss-dev\extensions\ms-vscode-remote.remote-containers-0.117.1\scripts
Sending build context to Docker daemon   7.68kB
Step 1/2 : FROM alpine:3.11.2
 ---> cc0abc535e36
Step 2/2 : RUN apk add --no-cache       nodejs  git     openssh-client  docker-c
li      ;
 ---> Using cache
 ---> 17fa1847bf65
Successfully built 17fa1847bf65
Successfully tagged vsc-volume-bootstrap:latest
SECURITY WARNING: You are building a Docker image from Windows against a non-Win
dows Docker host. All files and directories added to build context will have '-r
wxr-xr-x' permissions. It is recommended to double check and reset permissions f
or sensitive files and directories.
[1377 ms] Cloning Github repository: Microsoft/vscode-remote-try-dotnetcore into /workspaces/vscode-remote-try-dotnetcore

[1377 ms] Start: Run: docker run -d --mount type=volume,src=vsc-remote-sample,dst=/workspaces -v /var/run/docker.sock:/var/run/docker.sock vsc-volume-bootstrap sleep infinity
[2110 ms] Start: Run: docker exec -i -u root 420c8e469b3b6bd03706bed584729f4de08ae34f535749725f0923c781693514 /bin/sh
[2123 ms] Start: Launching Remote-Containers helper.
[2123 ms] Start: Run in container: command -v git >/dev/null 2>&1 && git config --global credential.helper '!f() { node /tmp/vscode-remote-containers-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.js $*; }; f' || true
[2313 ms] 
[2313 ms] 
[2314 ms] Start: Run in container: cat <<'EOF-/tmp/vscode-remote-containers-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.js' >/tmp/vscode-remote-containers-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.js
[2317 ms] 
[2317 ms] 
[2317 ms] Start: Run in container: # Copy .ssh/known_hosts
[2321 ms] 
[2321 ms] 
[2321 ms] Start: Run in container: cat <<'EOF-/tmp/vscode-remote-containers-server-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.js' >/tmp/vscode-remote-containers-server-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.js
[2325 ms] 
[2325 ms] 
[2615 ms] Start: Run: docker exec -u root -e SSH_AUTH_SOCK=/tmp/vscode-ssh-auth-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.sock -e REMOTE_CONTAINERS_IPC=/tmp/vscode-remote-containers-ipc-e6844dda1fe3c773a441d1879ee9b8851b9fdb66.sock 420c8e469b3b6bd03706bed584729f4de08ae34f535749725f0923c781693514 git clone https://github.com/Microsoft/vscode-remote-try-dotnetcore /workspaces/vscode-remote-try-dotnetcore
Cloning into '/workspaces/vscode-remote-try-dotnetcore'...
[3363 ms] Start: Run in container: cat /workspaces/vscode-remote-try-dotnetcore/.devcontainer/devcontainer.json 2>/dev/null
[3366 ms] Start: Run in container: cat /workspaces/vscode-remote-try-dotnetcore/.devcontainer/devcontainer.json 2>/dev/null
[3370 ms] Start: Run in container: test -f /workspaces/vscode-remote-try-dotnetcore/.devcontainer/Dockerfile
[3374 ms] 
[3374 ms] 
[3374 ms] Start: Run: docker exec 420c8e469b3b6bd03706bed584729f4de08ae34f535749725f0923c781693514 docker build -f /workspaces/vscode-remote-try-dotnetcore/.devcontainer/Dockerfile -t vsc-vscode-remote-try-dotnetcore-530c3f5a1471c73527da5f01ad9a2a80 --build-arg VARIANT=3.1 --build-arg INSTALL_NODE=false --build-arg NODE_VERSION=lts/* --build-arg INSTALL_AZURE_CLI=false /workspaces/vscode-remote-try-dotnetcore/.devcontainer
Sending build context to Docker daemon  8.704kB
Step 1/8 : ARG VARIANT="3.1"
Step 2/8 : FROM mcr.microsoft.com/vscode/devcontainers/dotnetcore:0-${VARIANT}
 ---> 1a2f90b00d16
Step 3/8 : ARG INSTALL_NODE="true"
 ---> Using cache
 ---> d5d8b5d496db
Step 4/8 : ARG NODE_VERSION="lts/*"
 ---> Using cache
 ---> 076987310cbc
Step 5/8 : RUN if [ "${INSTALL_NODE}" = "true" ]; then su vscode -c "source /usr
/local/share/nvm/nvm.sh && nvm install ${NODE_VERSION} 2>&1"; fi
 ---> Using cache
 ---> 10e3c784a5dd
Step 6/8 : ARG INSTALL_AZURE_CLI="false"
 ---> Using cache
 ---> 0db0cd759a65
Step 7/8 : COPY library-scripts/azcli-debian.sh /tmp/library-scripts/
 ---> Using cache
 ---> dfb3c8baea67
Step 8/8 : RUN if [ "$INSTALL_AZURE_CLI" = "true" ]; then bash /tmp/library-scri
pts/azcli-debian.sh; fi     && apt-get clean -y && rm -rf /var/lib/apt/lists/* /
tmp/library-scripts
 ---> Using cache
 ---> 9e29436fbef7
Successfully built 9e29436fbef7
Successfully tagged vsc-vscode-remote-try-dotnetcore-530c3f5a1471c73527da5f01ad9
a2a80:latest
[3770 ms] Start: Run: docker rm -f 420c8e469b3b6bd03706bed584729f4de08ae34f535749725f0923c781693514
[3771 ms] Start: Run: docker inspect --type image vsc-vscode-remote-try-dotnetcore-530c3f5a1471c73527da5f01ad9a2a80
[3943 ms] Start: Run: docker create sha256:9e29436fbef79eac3e7ef3d3e2a73d41fe5d1d72206131577b7e414d642dae0b
[4016 ms] Remote-Containers server terminated (code: 137, signal: null).
[4192 ms] Start: Run: docker exec -i -u root 98529310c5f30286a2e364faa9569e90f9a6872cf1f9b91ae7d36970d6bd346e cat /etc/passwd
[4377 ms] 
[4377 ms] Error response from daemon: Container 98529310c5f30286a2e364faa9569e90f9a6872cf1f9b91ae7d36970d6bd346e is not running

[4378 ms] Start: Run: docker rm 98529310c5f30286a2e364faa9569e90f9a6872cf1f9b91ae7d36970d6bd346e
[4378 ms] Start: Run: docker ps -q -a --filter label=vsch.local.repository=https://github.com/Microsoft/vscode-remote-try-dotnetcore --filter label=vsch.local.repository.volume=vsc-remote-sample --filter label=vsch.local.repository.folder=vscode-remote-try-dotnetcore --filter label=vsch.quality=undefined
[4578 ms] Command failed: cat /etc/passwd

Updating this repo to .NET 6

Hey Team,
Following a discussion with @codemillmatt and @bamurtaugh, I have created an updated sample, targeting .NET 6. However, we are wondering if we should rename the current repo (vscode-remote-try-dotnetcore would be renamed vscode-remote-try-dotnet). As @codemillmatt said:

The issue with using dotnetcore in the template's name is that .NET Core does not exist as a platform any longer (end of support in December 2022). Now it's .NET, nothing else.

We came up with two options:

Archive that repo, create a new one called "dotnet", and update all docs: This will require to update a lot of places (both doc and in-product). This might be hard to do. We can still mention the new repo in the readme before archiving the repo, but it's one more click.
Rename that repo to vscode-remote-try-dotnet and let GitHub handle redirects

1 C# and C++ ?

I'm working on a project in C# that invokes c++. Is it a feasible scenario to push the development of both languages into the same docker container?

Is there a way I can use dotnet 6 preview by change something in dockerfile.

I am looking for testing dotnet 6. How I can do that by change something in dockerfile and devcontainer.json and dotnet 6 environment is ready for testing.

"Some projects had trouble loading" error on container startup

In the logs:

        A PackageReference to Microsoft.AspNetCore.App is not necessary when targeting .NET Core 3.0 or higher. If Microsoft.NET.Sdk.Web is used, the shared framework will be referenced automatically. Otherwise, the PackageReference should be replaced with a FrameworkReference.
[info]: OmniSharp.MSBuild.ProjectManager
        Successfully loaded project file '/workspaces/vscode-remote-try-dotnetcore/aspnetapp.csproj'.
/workspaces/vscode-remote-try-dotnetcore/aspnetapp.csproj
/usr/share/dotnet/sdk/3.0.101/Sdks/Microsoft.NET.Sdk/targets/Microsoft.NET.Sdk.DefaultItems.targets(150,5): Error: A PackageReference to Microsoft.AspNetCore.App is not necessary when targeting .NET Core 3.0 or higher. If Microsoft.NET.Sdk.Web is used, the shared framework will be referenced automatically. Otherwise, the PackageReference should be replaced with a FrameworkReference.

[info]: OmniSharp.MSBuild.ProjectManager
        Adding project '/workspaces/vscode-remote-try-dotnetcore/aspnetapp.csproj'
[info]: OmniSharp.MSBuild.ProjectManager
        Update project: aspnetapp

End of the Beta – Codespaces for Individuals November 09

This repo is missing important files

There are important files that Microsoft projects should all have that are not present in this repository. A pull request has been opened to add the missing file(s). When the pr is merged this issue will be closed automatically.

Microsoft teams can learn more about this effort and share feedback within the open source guidance available internally.

Merge this pull request

Error building example container: experimental session with v1 builder is no longer supported

Hi all,

I just stumbled upon this repo when trying out the Remote Containers functionality in VSCode. The Node example works fine out of the box, but this example gives an error when the container is initially build:

Sending build context to Docker daemon  8.704kB
Error response from daemon: experimental session with v1 builder is no longer supported, use builder version v2 (BuildKit) instead.

A bit of searching leads to suspecting latest updates of docker do cause this problem since a few weeks.

Bit extra info: MacOS Catalina 10.15.7
Docker 2.4.2.0 (Edge)

Update: turning off 'experimental features' in Docker resolves the problem. I will leave this open as you might want to address this, but feel free to close if there is nothing you can do about it.

Could the container have the C# DevKit extensions installer by default ?

That would be awesome !

libhostpolicy.so: file too short

The host machine has a duel boot of Manjaro 18.04 and WIN10

Following the instructions here , I receive the following error as soon as I try and run dotnet restore when using Manjaro but works as expected on the WIN10 partition.

Failed to load H���, error: /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.11/libhostpolicy.so: file too short
An error occurred while loading required library libhostpolicy.so from [/usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.11]

# pwd
/workspaces/vscode-remote-try-dotnetcore
# ls -hl /usr/share/dotnet/shared/Microsoft.NETCore.App/2.1.11/ | grep lib
-rwxr-xr-x 1 1004 sudo 3.0M Apr 17 21:26 libclrjit.so
-rwxr-xr-x 1 1004 sudo 9.8M Apr 17 21:27 libcoreclr.so
-rwxr-xr-x 1 1004 sudo 688K Apr 17 21:27 libcoreclrtraceptprovider.so
-rwxr-xr-x 1 1004 sudo 1.1M Apr 17 21:27 libdbgshim.so
-rwxr-xr-x 1 1004 sudo    0 Apr 17 23:57 libhostpolicy.so
-rwxr-xr-x 1 1004 sudo    0 Apr 17 21:27 libmscordaccore.so
-rwxr-xr-x 1 1004 sudo    0 Apr 17 21:27 libmscordbi.so
-rwxr-xr-x 1 1004 sudo    0 Apr 17 21:27 libsos.so
-rwxr-xr-x 1 1004 sudo    0 Apr 17 21:27 libsosplugin.so
-rw-r--r-- 1 1004 sudo    0 Apr 17 22:21 mscorlib.dll

localhost:5000 does not contain anything on macOS with Docker Desktop

I'm using this dev container exactly like described in readme. However, when VSCode opens Safari with localhost:5000/ nothing is displayed. The same holds true for the internal browser of VSCode as well as Chrome. After trying around, I figured out that 127.0.0.1:5000 does show the website without any problems (on all browsers).

When I change the port to 8080 everything works fine. I made the required changes in my fork: https://github.com/suchja/vscode-remote-try-dotnet With those it works fine for me now.

It is very inconvenient to always change the address from localhost to 127.0.0.1 in the browser. So is there any solution to this problem? Obviously it is possible to use port 8080 instead, but I guess there was some reason why it was not chosen in the first place.

Any help would be greatly appreciated!!!

PS:
I'm using Docker Desktop 4.28.0 on Intel Mac with macOS Sonoma 14.4