I have asp core api project and i am using visual studio 2017 to run my project.
After i renamed the docker container that was previously created using visual studio using this command on command line,
docker rename CONTAINER NEW_NAME
I receive the following message when i try to run the project again in visual studio.
Thanks for the help
Can not find docker container with the name starting with 'previous_container_name'.
Delete the .vs folder in your solution directory (close the solution first), the Docker image name seems to be cached somewhere in there.
This error started happening to me when someone on the team unchecked the build checkbox for the docker-compose project. Make sure it is enabled in Build -> Configuration Manager
I had a similar problem, and it was caused because I started Docker after opening the project. VS does some things with Docker on opening of the project, and will fail if Docker is not started.
Lesson learned: make sure Docker is running before starting Visual Studio. If Docker is not started, then start Docker, close your solution, and re-open it.
VS will re-create the container as it opens the project.
This happened for me because I stopped a container manually via the commandline, then Visual Studio got confused.
To get round the issue I simply added a single ' ' space character to docker-compose.yml and saved the file. This forced Visual Studio to restart the container and connect to it.
I'm sure starting/stopping Visual Studio would also have worked, but the whitespace change was nice and fast.
I also have the similar problem.
These steps always help me to solve the issues.
Solution 1:
1- Close VS
2- delete obj folder of root solution folder.
3- delete obj folder of all projects which are involved in docker-compose file.(example all APIs)
4- Open VS
5- Remove the docker-compose project from solution and add it again.
During the creation process, don't overwrite the old files with new ones, to prevent deletion of you current docker-compose.yml configuration.
Solution 2:
On the first time of container creation, copy the creation command:
example: docker-compose -f "[path]\docker-compose.yml" -f "[path]\docker-compose.override.yml" -f "[path]\docker-compose.vs.debug.g.yml" -p dockercompose17926074389345686639 --no-ansi up -d --no-build --force-recreate --remove-orphans
any time there is an error just run this command manually.
if anybody could find a constant solution please also let us know.
One more cause is using solution folders for your docker project and a version of Visual Studio 2017 less than 15.9, upgrading to 15.9+ fixed this for me, see this issue.
In my case i have tried all of those but solution is very simple in V.S. 2019
Before all there is a bugfix packet for visual studio 2017 even if you using 19 beta, for this on https://visualstudio.microsoft.com/vs/
Download and install that pocket.
For automatically composing also you should add Docker Compose Support follow this link https://learn.microsoft.com/tr-tr/dotnet/standard/containerized-lifecycle-architecture/design-develop-containerized-apps/visual-studio-tools-for-docker
1-) Right click to targeted project root folder on solution explorer that contains Dockerfile and select add-> Docker Support it will ask you its always contains would you like to create new one? Click yes. It will create new Dockerfile.
You will see some changes in new Dockerfile like your project changes or nuget package changes affectness
2-) Right click the newly replaced Dockerfile and Build Image.
It will successfully build
3-) Choose debugger as Docker instead IIS Express vs. Even don't use other debugger while developing project if you do not need
In my case, I had both the "image" section and the "build" section in my docker-compose.yml. I just removed the build section because I wanted it to pull an image from the docker registry, and now it is working.
If your project uses Launch profiles to run, I fixed this with the following steps:
Open Manage Docker compose launch settings VS.
Select the Launch Profile you are currently using to run the application.
Check id the specific service is selected in the launch profile or not. All the services you intent to run should be part of the Launch profile.
Related
excuse me for my English.
Long time ago, I installed a laravel project with docker in windows 10 with WSL2 using DEBIAN; now, I want to resume it, i.e I want to continue developing the project. My problem is that I do not know where is that project folder in Debian.
The above image show the docker image runnig.
I want to locale my project folder in debian, and continue developing the project, so ¿how Do I do this?
First click on CLI icon on your app docker container (fastfoot-api_laravel.test_1):
And enter pwd command (this will most likely be the project directory, something like: /app, /var/www/app, etc.). Alternatively, you can try to find / -name "composer.json".
Then open windows file exporer, click in address input and type \\wsl$.
After this navigate to your docker container (probably "debian*" name) and to the previously found folder structure (/var/www/.. etc.)
I have a project set up to run locally in Docker with docker-compose. Until recently, it's been working fine. I don't believe I changed anything that should affect this (except maybe a VS upgrade?), and I've even tried rolling back to an older commit. In all cases, I'm now getting an error message, which appears in Visual Studio's output window as:
docker exec -i f93fb2962a1e sh -c ""dotnet" --additionalProbingPath /root/.nuget/packages --additionalProbingPath /root/.nuget/fallbackpackages "bin/Debug/netcoreapp3.1/MattsTwitchBot.Web.dll" | tee /dev/console"
sh: 0: getcwd() failed: No such file or directory
It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download
I've tried a variety of different things (changing the base image in the Docker file, deleting old images and containers, and more) but I keep getting the same error message. The weird thing is that when I do a File->New, Visual Studio generates a very similar looking Docker file and it works fine. I have no idea what the problem is, but I'm hoping someone here can spot it.
My full repo is available on Github. Here is the docker for the asp.net core project:
FROM mcr.microsoft.com/dotnet/core/aspnet:3.1-buster-slim AS base
WORKDIR /app
EXPOSE 80
EXPOSE 443
FROM mcr.microsoft.com/dotnet/core/sdk:3.1-buster AS build
WORKDIR /src
COPY ["MattsTwitchBot.Web/MattsTwitchBot.Web.csproj", "MattsTwitchBot.Web/"]
COPY ["MattsTwitchBot.Core/MattsTwitchBot.Core.csproj", "MattsTwitchBot.Core/"]
RUN dotnet restore "MattsTwitchBot.Web/MattsTwitchBot.Web.csproj"
COPY . .
WORKDIR "/src/MattsTwitchBot.Web"
RUN dotnet build "MattsTwitchBot.Web.csproj" -c Release -o /app/build
FROM build AS publish
RUN dotnet publish "MattsTwitchBot.Web.csproj" -c Release -o /app/publish
FROM base AS final
WORKDIR /app
COPY --from=publish /app/publish .
ENTRYPOINT ["dotnet", "MattsTwitchBot.Web.dll"]
and the docker-compose for the solution (even without the Couchbase stuff I'm getting the same error, but I'm pasting it here for completeness):
version: '3.4'
services:
couchbase:
image: couchbase:6.5.0-beta2
volumes:
- "./couchbasetwitchbot:/opt/couchbase/var" # couchbase data folder
ports:
- "8091-8096:8091-8096" # https://docs.couchbase.com/server/current/install/install-ports.html
- "11210-11211:11210-11211"
mattstwitchbot.web:
image: ${DOCKER_REGISTRY-}mattstwitchbotweb
build:
context: .
dockerfile: MattsTwitchBot.Web/Dockerfile
environment:
Couchbase__Servers__0: http://couchbase:8091/ # Reference to the "couchbase" service name on line 4
depends_on:
- couchbase # Reference to the "couchbase" service name on line 4
command: ["./wait-for-it.sh", "http://couchbase:8091"]
I don't have enough reputation to comment but I think it might be your .csproj file. You mentioned you upgraded Visual Studio. Since the .csproj file contains information about the project (including references to system assemblies), and you are copying it in your Dockerfile, it's possible that:
The .csproj file needs to be updated since you updated VS.
The dotnet core version in your dockerfile 'FROM' statement is a different version than what you're using locally.
Maybe test this by starting a new project and adding your source, then do a diff on the old and new .csproj files. You can also backup the original and try modifying the .csproj file manually. I found a blog post that demonstrates upgrading a vs2015 csproj file to vs2017. Hopefully it helps.
Because I don't have enough reputation I cannot comment on your question.
But one thing that puzzles me is the fact that you are using as base image an image that doesn't have .Net SDK and if you try to run a command that requires an SDK looks it fails
I am assuming, in the container, f93fb2962a1e is using the image created by the docker file you posted in the question
getcwd() error, means the solution lost context to path. I found that completely removing the dock-compose solution and the associated Dockerfile file from the project fixed the problem. It's hacky but works if you're in a bind.
I had a similar issue and am debugging code that has previously worked. Simply closing my terminal and re-opening it resolved the issue for me. I am using WSL, and have changed some environment variables that appear to have caused the initial issues.
I belive that your current working directory got deleted or path to working directory was reseted. But it will be the first option because update of VS may removed directory /tmp on your docker machine so its not there anymore, and it will be created on some external event.
Or set port to blocking of connection to your docker machine.
Check connection to docker machine
Check existence of folder that is used as working directory on docker machine
If you didnt found problem then continue with this:
docker exec --it {containerID} /bin/sh
you can use this official docker debugging article
with this, follow the directories that is docker trying to access and check
for their existence.
With this debugging you shoud be able to discover problems.
I hope that it helped you
When running a docker-compose.dcproj project from the Visual Studio 2019 (using regular F5 Debug) it automatically executes this command (unrelated parts removed):
docker-compose -f -p dockercompose5867848916081622061 up
How do I force to regenerate this hash dockercompose5867848916081622061 or replace it with my own value? The issue is that if the solution folder was copied from another project the containers are unable to respond to any incoming requests and just hang
UPD: changing this name didn't help me, getting a meaningful name would still be helpful though
As of Visual Studio 16.9, you can use <DockerComposeProjectName>my-docker-compose-project</DockerComposeProjectName> in the dcproj file to specify the docker-compose project name.
See https://github.com/microsoft/DockerTools/issues/171
Is there an easy way to find files that are not checked into my repository in my Visual Studio project?
In the past, there's been times when I get my code base from the repo only to realize that some files -- for some reason -- had not been checked into the repository.
I recently got a new laptop and downloaded the code for my app onto my new machine. I'm now getting an error when I run the app on the new laptop but on the old one it runs perfectly fine. My first thought was that there were configuration differences between two machines so I downloaded the code into a new folder on the old machine and started having the same error that I'm having on the new laptop. If I run the app from the original folder on the old machine, it runs fine.
This makes me think that I may have some differences in the code between what's on the repo and the original folder. As a result, if I get the code from the repo, I have the error. If I try to check in the code from the original folder on the old laptop, Visual Studio tells me that there's nothing to check in.
So, is there an easy way for me to see if there's any file that is not checked into the repo on my old laptop?
BTW, I'm running Visual Studio 2019 -- with the latest updates/patches -- and my repo is on Azure DevOps and uses TFVC.
Running tf vc status /format:detailed /recursive from a Visual Studio Developer Commandline in your workspace root should give you a good overview of files not checked in and files with pending changes.
C:\Users\JesseHouwing\source\Workspaces\xxx>tf vc status /format:detailed /recursive
-----------------------------------------------------------------------------------------------------------------------
Detected Changes:
-----------------------------------------------------------------------------------------------------------------------
$/xxx/test.txt
User : Jesse Houwing
Date : zaterdag 27 juli 2019 21:20:00
Lock : none
Change : add
Workspace : SHARKIE
Local item : [SHARKIE] C:\Users\JesseHouwing\Source\Workspaces\xxx\test.txt
0 change(s), 1 detected change(s)
It should auto-detect files unless you specify the /nodetectchanges flag.
Or, if your .tfignore file is well specified, you can run tf vc add * /recursive to automatically create a pending change for all files that are currently not under version control. If needed, edit your tfignore file before running the add command. Add /noignore to bypass the ignore file, but that may add bin and obj and packages folders as well, be careful.
tf.exe is hidden deep in the bowels of Visual Studio, easiest way to get access to it is to use the Developer Command Prompt:
My installation has put it here:
C:\Users\JesseHouwing\source\Workspaces\xxx>where tf
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\TF.exe
I have added docker compose to my project. When I debug the project it loads the docker compose file. In the override yml I have specified a postgresql image and volume so it automatically brings up the development database. This is great because you can clone repo and not have to install any local software apart from docker.
The only thing that is not good is running tests. When I run tests it doesn't bring up the database container, it just executes the code inside the test project. So tester has to manually start the database image.
I feel like I am probably doing something wrong. Is there a better way to make the tests work with the visual studio docker compose support so it brings up the database automatically?
I thought about running the tests inside the docker file but I think that might get in the way of development. What is a good approach here?
I would not recommend running tests inside your Dockerfile. This will complicate your development process as you have said.
In terms of the database, you can just run it outside of docker-compose so that it is always running in the background. Just remove the postgres config from your docker-compose.yml and run postgres with docker run ... instead. This way it will always be running until you stop it with docker stop ...
docker run -v /tmp/pgdata:/var/lib/postgresql/data -e POSTGRES_PASSWORD=<PASSWORD> -d postgres