I have the following configuration in my .csproj file to mount my AWS credentials when running .NET core in a Docker container:
<Project Sdk="Microsoft.NET.Sdk.Web">
<PropertyGroup>
<TargetFramework>netcoreapp3.1</TargetFramework>
<GenerateRuntimeConfigurationFiles>True</GenerateRuntimeConfigurationFiles>
<DockerDefaultTargetOS>Linux</DockerDefaultTargetOS>
<DockerfileRunArguments>-v /C/Users/myname/.aws:/root/.aws</DockerfileRunArguments>
</PropertyGroup>
However, I need this to work across different development environments. I've tried replacing myname with ${env.UserName} or %USERNAME% but in both cases I get Error response from daemon: mkdir C:\Users\[variable is here]: Access is denied.
The docker run command is fine if I hard-code my user name as shown.
Related
I've created a complete new Xamarin Forms App project in Visual Studio for Mac and added it to a GitLab repository. After that I created a .gitlab-ci.yml file for setting up my CI build. But the problem is that I get error messages:
error MSB4019: The imported project "/usr/lib/mono/xbuild/Xamarin/iOS/Xamarin.iOS.CSharp.targets" was not found. Confirm that the expression in the Import declaration "/usr/lib/mono/xbuild/Xamarin/iOS/Xamarin.iOS.CSharp.targets" is correct, and that the file exists on disk.
This error pops up also for Xamarin.Android.Csharp.targets.
My YML file look like this:
image: mono:latest
stages:
- build
build:
stage: build
before_script:
- msbuild -version
- 'echo BUILDING'
- 'echo NuGet Restore'
- nuget restore 'XamarinFormsTestApp.sln'
script:
- 'echo Cleaning'
- MONO_IOMAP=case msbuild 'XamarinFormsTestApp.sln' $BUILD_VERBOSITY /t:Clean /p:Configuration=Debug
Some help would be appreciated ;)
You will need a mac os host to build Xamarin.iOS application and AFAIK it's not there yet in GitLab. You can find the discussion here and private beta here. For now, I would recommend going your own MacOS Host and registered GitLab runner on that host:
https://docs.gitlab.com/runner/
You can set up the host where you want (VM or Physical device) and install the GitLab runner and Xamarin environment there, tag it and use with the GitLab pipelines as with any other shared runner.
From the comments on your question, it looks like Xamarin isn't available in the mono:latest image, but that's ok because you can create your own docker images to use in Gitlab CI. You will need to have access to a registry, but if you use gitlab.com (opposed to a self-hosted instance) the registry is enabled for all users. You can find more information on that in the docs: https://docs.gitlab.com/ee/user/packages/container_registry/
If you are using self-hosted, the registry is still available (even for free versions) but it has to be enabled by an admin (docs here: https://docs.gitlab.com/ee/administration/packages/container_registry.html).
Another option is to use Docker's own registry, Docker Hub. It doesn't matter what registry you use, but you'll have to have access to one of them so your runners can pull down your image. This is especially true if you're using shared runners that you (or your admins) don't have direct control over. If you can directly control your runners, another option is to build the docker image on all of your runners that need it.
I'm not familiar with Xaramin, but here's how you can create a new Docker image based on mono:latest:
# ./mono-xamarin/Dockerfile
FROM mono:latest # this lets us build off of an existing image rather than starting from scratch. Everything in the mono:latest image will be available in this image
RUN ./install_xamarin.sh # Run whatever you need to in order to install xamarin or anything else you need.
RUN apt-get install git # just an example
Once your Dockerfile is written, you can build it like this:
docker build --file path/to/Dockerfile --tag mono-xamarin:latest
If you build the image on your runners, you can use it immediately like:
# .gitlab-ci.yml
image: mono-xamarin:latest
stages:
- build
...
Otherwise you can now push it to whichever registry you want to use.
The BOT works, but I can't deploy it to Azure using the CLI instructions here.
https://learn.microsoft.com/en-us/azure/bot-service/bot-builder-deploy-az-cli?view=azure-bot-service-4.0&tabs=csharp#option-1-existing-app-service-plan
Here are my relevant CLI commands.
az bot prepare-deploy --lang Csharp --code-dir "./Source/Repos/MyBot.Bot/MyBot.Bot" --proj-file-path "C:\Users<username>\Source\Repos\MyBot.Bot\MyBot.Bot\MyBot.Bot.csproj"
az webapp deployment source config-zip --resource-group "BOTQnARG" --name "MYBOTAPP" --src "C:\Users<username>\Source\Repos\MyBot.Bot\MyBot.Bot\Data.zip" --timeout 3600
When I include a .deployment file in the Bots root directory zip file, I get this error message in Deployment Center (Preview) for the App Service. I also get a Zip Deployment Failed message in the Command Prompt window.
Using the following command to generate deployment script: 'azure site deploymentscript -y --no-dot-deployment -r "D:\local\Temp\zipdeploy\extracted" -o "D:\home\site\deployments\tools" --aspNetCore "C:\Users<username>\Source\Repos\MyBot\MyBot\MyBot.csproj"'.
D:\Program Files (x86)\SiteExtensions\Kudu\91.21119.4922\bin\node_modules\kuduscript\lib\generator.js:90
throw new Error("The project file path should be a sub-directory of the repository root"); } ;
^
Error: The project file path should be a sub-directory of the repository root
Here is a sample of what my root directory for the BOT looks like.
BEG UPDATE 1
I removed the . in the Project name and folders, but it still didn't work.
Here is my .deployment file.
[config]
SCM_SCRIPT_GENERATOR_ARGS=--aspNetCore "C:\Users\<username>\Source\Repos\MyBot\MyBot\MyBot.csproj"
END UPDATE 1
Any idea what's happening and how to work around this?
I finally got it to work. The .deployment file should look like this. I used Notepad++ to edit it.
[config]
SCM_SCRIPT_GENERATOR_ARGS=--aspNetCore "MyBot.csproj"
When you run the following command, it adds unnecessary information to the file.
az bot prepare-deploy --lang Csharp --code-dir "./Source/Repos/MyBot/MyBot" --proj-file-path "C:\Users\<username>\Source\Repos\MyBot\MyBot\MyBot.csproj"
In testing Docker, I used Visual Studio to containerize one project in a solution. Folder structure like this:
/AlfaModulesPoc.sln
/Modules/AlfaCom/AlaCom.csproj
/Modules/AlfaCom/Dockerfile
I did this by right-clicking the project --> Add... --> Docker Support... and choose "Linux":
VS then created the Dockerfile, that looked good on paper, but in reality could not be used since the paths in that Dockerfile was based on the Dockerfile being placed in the solution folder (2 folders "up"), but it was placed inside the project folder (as I expected).
Building the image from here did not work at all, files could not be found etc.
The workaround was to also add "Container Orchestrator Support..." which created a new project called "docker-compose" in the solution root folder, and a docker-compose.yml file that looks like this:
version: '3.4'
services:
alfacom:
image: ${DOCKER_REGISTRY-}alfacom
build:
context: .
dockerfile: Modules/AlfaCom/Dockerfile
As soon as I added this Orchestration Support, VS also proceeded in creating the image automatically and starting it. At this point, I did not pay attention to the Output logs.
When checking Visual Studio Output window, I was the expected console logs that the program gives out, and I also saw data being handled in the Redis server, since the program adds data to Redis. I also looked in the Docker Desktop application, and saw the same console logs. Looked good to me.
I then stopped it, and tried to start it manually, via console, like this:
PS C:\Git\alfa\AlfaModulesPoc> docker-compose -f "C:\Git\alfa\AlfaModulesPoc\docker-compose.yml" -p dockercompose5247976386926556655 --no-ansi up -d
but that failed with the error:
Step 6/20 : COPY
["../Submodules/Core/CoreCommons/CoreCommons/CoreCommons.csproj",
"../Submodules/Core/CoreCommons/CoreCommons/"] Service 'alfacom'
failed to build: COPY failed: Forbidden path outside the build
context: ../Submodules/Core/CoreCommons/CoreCommons/CoreCommons.csproj
()
Question 1: Why? I am using the .yml file, and that files says that context: . so why this error?
And its not until I realize that VS actually had 3 different yml files. The command VS executed was:
PS C:\Git\alfa\AlfaModulesPoc> docker-compose -f "C:\Git\alfa\AlfaModulesPoc\docker-compose.yml" -f "C:\Git\alfa\AlfaModulesPoc\docker-compose.override.yml" -f "C:\Git\alfa\AlfaModulesPoc\obj\Docker\docker-compose.vs.debug.g.yml" -p dockercompose5247976386926556655 --no-ansi up -d
and it is the very hidden, auto-generated file docker-compose.vs.debug.g.yml that contains the most settings:
version: '3.4'
services:
alfacom:
image: alfacom:dev
container_name: AlfaCom
build:
target: base
labels:
com.microsoft.created-by: "visual-studio"
com.microsoft.visual-studio.project-name: "AlfaCom"
environment:
- NUGET_FALLBACK_PACKAGES=
volumes:
- C:\Git\alfa\AlfaModulesPoc\Modules\AlfaCom:/app
- C:\Users\wagge\vsdbg\vs2017u5:/remote_debugger:rw
- C:\Users\wagge\.nuget\packages\:/root/.nuget/packages:ro
entrypoint: tail -f /dev/null
labels:
com.microsoft.visualstudio.debuggee.program: "dotnet"
com.microsoft.visualstudio.debuggee.arguments: " --additionalProbingPath /root/.nuget/packages \"/app/bin/Debug/netcoreapp3.1/AlfaCom.dll\""
com.microsoft.visualstudio.debuggee.workingdirectory: "/app"
com.microsoft.visualstudio.debuggee.killprogram: "/bin/sh -c \"if PID=$$(pidof dotnet); then kill $$PID; fi\""
tty: true
Running the same 3-yml-command that VS did removes the error:
Question 2: What is it in this .yml file that fixes it? is it the C:\Git\alfa\AlfaModulesPoc\Modules\AlfaCom:/app line under volumes:?
So, the container is now running, but not working.
Any yml files that visual studio uses "behind the scenes" should be ignored it seems.
The problem is using project references, if those exits outside of your solution directory, you need to have NuGet references instead
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
I am trying to setup jenkins on docker in my windows machine. Everything was going smooth until I configured the maven goal in Jenkins. It looks like maven is overlooking the Jenkins_home path configured while starting the docker. I used the following command during startup
docker run -p 8080:8080 -p 50000:50000 -v //D/jenkins:/var/jenkins_home Jenkins
I also tried the following
docker run -p 8080:8080 -p 50000:50000 -v jenkins_home://D/jenkins_workspace jenkins
but I keep getting the error
[crazywebapp_dev] $ mvn clean install
FATAL: command execution failed java.io.IOException: error=2, No such
file or directory at java.lang.UNIXProcess.forkAndExec(Native Method)
at java.lang.UNIXProcess.(UNIXProcess.java:247) at
java.lang.ProcessImpl.start(ProcessImpl.java:134) at
java.lang.ProcessBuilder.start(ProcessBuilder.java:1029) Caused:
java.io.IOException: Cannot run program "mvn" (in directory
"/var/jenkins_home/workspace/crazywebapp_dev"): error=2, No such file
or directory at
java.lang.ProcessBuilder.start(ProcessBuilder.java:1048) at
hudson.Proc$LocalProc.(Proc.java:249)
I believe it has got to do something with maven because the Jenkins workspace is getting created in my D: drive and the code is checked out successfully from bit bucket and the workspace contents shows up in Jenkins. I have also noticed that even though the workspace is created in my D: drive, Jenkins_home still shows up as /var/Jenkins_home in the Jenkins config page. Please help me figure this out.
I have also noticed that even though the workspace is created in my
D: drive, Jenkins_home still shows up as /var/Jenkins_home in the
Jenkins config page. Please help me figure this out.
From the containers perspective, there is no D: drive, the jenkins_home will always be /var/jenkins_home inside the container.
The syntax -v //D/jenkins:/var/jenkins_home means mount D:\jenkins onto /var/jenkins_home inside the container. This will effectively just replace or backup the containers jenkins home in the jenkins folder.
The syntax -v jenkins_home://D/jenkins_workspace is not useful. It means "create" a /D/jenkins_workspace directory inside the container and use a named volume called jenkins_home to backup this folder. This is not useful.
The main problem that you have, is that maven is not installed inside the jenkins container. Thus jenkins clearly can't find it. You need to configure maven to be installed. You can do that in jenkins, by going to:
Manage Jenkins > Configure System > Maven section and then configure it to install maven automatically.