I am trying to run my selenium tests in Docker but I don't see any containers running and don't see anything in the docker logs.
I have created 3 different versions of DockerFiles which can be found in https://github.com/devanasri/googlesearchauto
The commands I am using to create image and start container is
docker build -t googlesearchauto .
docker run -it automation
When run above commands to start the container and run selenium tests, nothing happens and sometimes I get below error when trying to start the container.
The command could not be loaded, possibly because:
* You intended to execute a .NET application:
The application 'test' does not exist.
* You intended to execute a .NET SDK command:
No .NET SDKs were found.
Download a .NET SDK:
https://aka.ms/dotnet-download
Learn about SDK resolution:
https://aka.ms/dotnet/sdk-not-found
I tried to run each version of the DockerFile but all of them not working. Any help is appreciated.
Related
I'm facing the issue that a .Net Core WPF application automatically opens a console window when started. This only happens when build inside a Docker container. When I build it directly on my PC, only the actual application window opens.
My best guess is that this is an issue with the operating system the .Net Core image is based on. The .Net Core SDK Docker Hub Repo knows the following tags: 3.1-nanoserver-1809, 3.1-nanoserver-1903, 3.1-nanoserver-1909, 3.1-nanoserver-2004, 3.1-nanoserver-2009. I was able to confirm the issue with the first three tags, but the 2004 and 2009 tags do not run on my machine, so I need someone to try this out and either confirm my theory (which would mean that it should not happen on at least on of these images) or to come up with a better explanation of why this is happening.
This is reproducible with the default .Net Core WPF app Visual Studio creates for you. Here is a Dockerfile to test it out:
FROM mcr.microsoft.com/dotnet/core/sdk:3.1 AS build
WORKDIR /src
COPY . ./
RUN dotnet build -c Debug -o out
FROM stefanscherer/chocolatey
WORKDIR /app
RUN choco install -y 7zip
# Depending on your project setup it might be src/[project name]/out
COPY --from=build /src/out ./test
RUN 7z a -y test.zip ./test/*
You can build the image and extract the compiled program with the following commands:
docker build -t testimage .
docker run -d --name testcontainer testimage
docker stop testcontainer
docker cp testcontainer:app/test.zip .
I was able to reproduce this problem on both 3.1-nanoserver-2009 and 3.1-nanoserver-2004 for you.
I think the problem is related to the warning printed out during build:
warning NETSDK1074: The application host executable will not be customized because adding resources requires that the build be performed on Windows (excluding Nano Server).
If that's the case, then it seems that it is a limitation of the nanoserver base image, and unfortunately it looks like this problem still has not been resolved, because it's still present when building in mcr.microsoft.com/dotnet/nightly/sdk:5.0.
Here's a related pull request that might shed some light on the subject.
Having said that, I think the only option for now is to use windows image other than nanoserver (alternatives can be found here). I didn't find any image that would come with .NET Core SDK preinstalled (I didn't put much effort into finding it though), but it should be fairly simple to set it up. In the following example I used servercore image since it is much more lightweight than windows image.
FROM mcr.microsoft.com/windows/servercore:20H2 AS sdk
WORKDIR /dotnet
# Download the official .NET Core install script
RUN powershell -c "Invoke-WebRequest -Uri https://dot.net/v1/dotnet-install.ps1 -OutFile dotnet-install.ps1"
# Run the install script
RUN powershell -c "& ./dotnet-install.ps1 -InstallDir ."
# Add the installed executable to PATH
RUN setx PATH "%PATH%;/dotnet"
FROM sdk AS build
# Do your stuff here
Here you'll find the documentation for the install script.
I also did confirm that the produced application did not spawn console window when run.
As #Grx70 mentioned, the underlying nanoserver image is the problem.
There is another .NET core image, but it is based on the servercore image.
This saves the manual installation of .NET Core within the image and has everything ready at hand.
Here you can find all version of the .NET Core Image:
DockerHub
Way down at the bottom, you'll find the heading Windows Server Core 2019 amd64 Tags and the associated mcr.microsoft.com/dotnet/sdk:5.0-windowsservercore-ltsc2019 image.
This image no longer produced a console window when I built something :)
I am trying to build a web deploy package on the .net core sdk docker image to be used to deploy to a windows server running iis (the deployment being done on a seperate windows vm). This is the command I am running (this can also be done via the publish UI in visual studio):
dotnet publish src/SpaceForce.sln -c release -o out -p:WebPublishMethod=Package;PackageAsSingleFile=True;DesktopBuildPackageLocation="../Package/SpaceForce.WebAPI.zip"
On Windows this produces a folder with the following files and then when i'm ready to deploy, i just run the cmd file:
SpaceForce.WebAPI.deploy.cmd
SpaceForce.WebAPI.deploy-readme.txt
SpaceForce.WebAPI.Parameters.xml
SpaceForce.WebAPI.SetParameters.xml
SpaceForce.WebAPI.SourceManifest.xml
SpaceForce.WebAPI.zip
but on Linux (.net core sdk docker image) it produces the following error:
/usr/share/dotnet/sdk/3.1.300/Sdks/Microsoft.NET.Sdk.Publish/targets/PublishTargets/Microsoft.NET.Sdk.Publish.MSDeployPackage.targets(97,5): error MSB6004: The specified task executable location "%ProgramW6432%/IIS/Microsoft Web Deploy V3/msdeploy.exe" is invalid. [/home/osboxes/src/spaceforce/src/SpaceForce.WebAPI/SpaceForce.WebAPI.csproj]
on this page, it has this note but i'm not sure if this applies in my case:
The dotnet msbuild command is a cross-platform command and can compile ASP.NET Core apps on macOS and Linux. However, MSBuild on macOS and Linux isn't capable of deploying an app to Azure or other MSDeploy endpoints.
If i can build on linux, i am happy to run the cmd file on a windows box for deployment. Is it possible to build this package on linux?
As you quoted, MSDeploy is a Windows-only thing. Using the WebPublishMethod switch tries to run "%ProgramW6432%/IIS/Microsoft Web Deploy V3/msdeploy.exe", which is obviously not present in the linux container.
To publish an app from a linux environment to an IIS server you have to publish the app without the WebDeploy specific features and then send the published files to the IIS server. On the server you configure an app with a set physical path and move the published files into that path.
To get the files from the docker image you have to create a temporary container and copy the files
# Dockerfile
RUN dotnet publish src/SpaceForce.sln -c Release -f netcoreapp3.1 -o /out
# bash script to get the publish dir from the image
imageId=$(docker create <IMAGE_NAME>)
docker cp $imageId:/out/ <HOST_DIR>
docker rm $imageId
This article should get you started.
Hope this helps a litte 🙂
I have recently tried to do some C# development on my Linux box with the help of the docker image microsoft/dotnet which works great within the docker image.
Yet I would like to use Visual Studio Code with the C# extension powered by OmniSharp to get intellisense/autocompletion, and the other benefits of that extension within that editor.
The problem is that .NET Core is not supported on my distribution (Arch). There is an AUR package but it has been more often broken than working and I would rather stick with my docker image to run dotnet in a container.
Hence my question is: can I make Visual Studio Code's C# extension which is running on my host OS use the dotnet tools available in the docker image?
Thanks
Yep, you can hook your C# code in the container via Docker Volumes. Try something like this:
docker run --name app -d -p 5000:5000 -v <your-project-path>:/app microsoft/dotnet
Note: Make sure that you are using the .NET Core SDK image.
I have run through the boot2docker virtual machine setup tutorial in the docker toolbox https://www.docker.com/toolbox.
Using window 10 as my base, I managed to get virtualbox running from kitematic with Linux default 4.0.9-boot2docker
When I start trying to run apt-get or yum to install things like NODE.JS or ASPNET I'm told that the files aren't found.
The end goal is to be able to run my aspnet docker images on my local environment.
Do I need to install aspnet, node, etc... on my docker server before I can start running aspnet docker images? If yes, how do I install them in the version of linux that has no apt-get or yum?
edit - note it is the ASPNET core documentation that seems to suggest I need to install things on the docker server. https://dotnet.readthedocs.org/en/latest/getting-started/installing-core-linux.html perhaps I can docker-build within the windows environment and docker-run from the linux VM without actually installing anything other than my docker image?
With docker you can focus on using application, not installation.
you needn't waste time on application installation that you can pull the image directly to get node.js or aspnet environments work in minutes.
So answer your question, you can have these environments ready via pull command:
docker pull node
docker pull microsoft/aspnet
Is it possible to run tests (written in C# with NUnit) with Jenkins on Linux OS?
I can find a lot of info on running NUnit tests with Jenkins but can't find any speak of my situation.
UPDATE
Looks like it's possible. I'll need to use a Master Jenkins in Linux to run a Slave Jenkins in Windows. Described in the article.
Looks like it's possible. I'll need to use a Master Jenkins in Linux to run a Slave Jenkins in Windows. Described in the article.
This turned out to be relatively painless using mono on Linux
1) Install NUnit Console.
sudo apt-get install monodevelop-nunit
2) Under Build in your Jenkins project "Add build step" "Execute shell" after your MSBuild step
cd "$WORKSPACE"
# so nunit does not fail on file operations
export MONO_IOMAP=all
nunit-console ./UnitTests/UnitTests.csproj
The only problem I ran into were failing tests involving NancyFx due to Nancy trying to access the projects bin/Debug directory. (The project runs normally with mono under the same environment setup) This turned out not to be a problem as we moved away from Nancy.