We have a .NET Core project in Visual Studio (2017) that has Docker support added. Our project relies on environment variables to configure itself at start up. As we understand it, in order to pass environment variable values to a container you specify them as arguments to the docker run command using -e.
When you run the containerized version of the project from Visual Studio by selecting the Docker profile, we noticed that Visual Studio executes a docker run command. However, we've not been able to figure out how to get Visual Studio to include our environment variable values when it runs the container.
Is there a way to tell Visual Studio to pass our environment variable values to a container it runs?
Note that we do not want to specify the environment variable values in the image since the values will change depending on where it is deployed to.
You can choose to include additional environment files to be passed to the docker run command by adding the following property to your .csproj file:
<DockerfileRunEnvironmentFiles>your_env_file.env</DockerfileRunEnvironmentFiles>
I have a command line .NET Core application that consumes a secret in the input arguments, like
mycli -ACCOUNT_KEY abcdef123=. For debugging purposes, I don't want to have this value in my source countrol, so I set it as an environment variable on my system that I'm then passing in the command line arguments. This is what I did:
In the system environment variables:
In the project settings:
In the .csproj file:
In the .gitignore:
In case your env variable does not change frequently, you can also put them in the Docker file , during the image-building process the env variable will be assigned to the container
FROM mcr.microsoft.com/dotnet/aspnet:6.0 AS base
WORKDIR /app
EXPOSE 80
ENV ASPNETCORE_ENVIRONMENT=dev
Related
Ok, this seems easy enough for Linux containers but I am trying to get this done using Windows Containers and its annoying that its so difficult.
I have a Windows Dockerfile which builds a project and part of the build process is to reversion the C# AssemblyInfo.cs files so that the built assemblies have a build version from the CI environment (Devops)
I am using a Powershell script https://github.com/microsoft/psi/blob/master/Build/ApplyVersionToAssemblies.ps1, it expects 2 Environment variables, one which I can hardcode so is not a problem, but the BUILD_BUILDNUMBER environment variable needs to be injected from Devops build system.
I have tried the following, none of which work
ARG BUILD_BUILDNUMBER
ENV BUILD_BUILDNUMBER=$BUILD_BUILDNUMBER
RUN ApplyVersionToAssemblies.ps1
and running
docker build -f Dockerfile --build-arg BUILD_BUILDNUMBER=1.2.3.4 .
also
RUN SETX BUILD_BUILDNUMBER $BUILD_BUILDNUMBER
RUN SETX BUILD_BUILDNUMBER %BUILD_BUILDNUMBER%
and a few other combinations that I dont recall, what I ended up doing which works but seems like a hack is to pass the BUILDNUMBER as a file via a COPY and then modifying the the Powershell script to read that into its local variable
So for the moment it works but I would really like to know how this is supposed to work via ARG and ENV for Windows Container builds
Windows Containers definitely feel like Linux containers poor cousin :)
Example for CMD in Docker Windows Containers:
ARG FEED_ACCESSTOKEN
ENV VSS_NUGET_EXTERNAL_FEED_ENDPOINTS="{\"endpointCredentials\": [{\"endpoint\":\"https://URL.com/_packaging/Name/nuget/v3/index.json\", \"username\":\"PATForPackages\", \"password\":\"${FEED_ACCESSTOKEN}\"}]}"
SHELL ["cmd", "/S", "/C"]
RUN echo %VSS_NUGET_EXTERNAL_FEED_ENDPOINTS%
I've created a build pipeline for my chatbot that uses mocha tests as part of the process. All tests pass on my local with VS Code, but they are failing during the pipeline build. The issue is missing environmental variables. However, I have added for each run via variables and it is still not working only in some cases. Some of the variables are coming through fine, but other continue to be null (and are causing failure of the build). I have checked and all the variable names are identical to my local .env file. Any ideas why some of the variables are coming across as null during pipeline build where others are fine?
This turned out to be an issue between my local test environment being Windows command line and the build pipeline being ubuntu. On Windows environmental variables are not case sensitive, but they are on Linux platforms such as ubuntu. I changed by yml file to use windows-latest instead of ubuntu-latest for the build and that fixed the problem. The key takeaway is:
Use Linux env variable naming regardless of your platform (all caps and underscores for spaces)
In case you already have many env variables in your project with mixed case, you can switch the OS in your build pipeline to Windows, but that is more of a workaround than a solution to the problem. That said, dealing with something relatively simple like botframework it should be fine to avoid having to recode and redefine all of your env variables.
My objective is to have a self contained Go Workspace per project.
Is it possible to retrieve a Go workspace and Go environment variables from a running Docker container to be used by an IDE or Text Editor for development?
I have already tried mapping a volume to the container with the go tools and dependencies. But that requires always setting the GOPATH to the current workspace, and requires to have the go tools and dependencies on the host.
You can at least set and pass those environment variable when launching your container:
docker run -e "GOPATH=/a/mounted/path" -v [host-src:]container-dest --rm -it <yourImage>
By using -v, you allow your host to share a folder with your container.
I am building a visual studio solution containing number of project. I wanted to disable multiprocess build, so , i tried setting an enviroment variable CL to /MP1. But it didn't worked in Jenkins while working in running the batch script for building solution using command line.
Good morning,
Log to your Jenkins server, and stop the Jenkins from the command line. While doing this, open your web-browser and refresh the Jenkins webpage to make sure it stopped(it will take around 5 seconds to stop the service). Then start again from the command line, it will update the variable. I did yesterday, to run my unit tests. It should work.
To set environment variables for individual projects, use the checkbox 'Prepare an environment for the run' and set what environment variables you want in the format 'ENV=value' in the Properties content box.
Otherwise, all I can suggest is that you haven;t restarted the Jenkins service after setting your variable in Windows.
You can also used the EnvInject plugin, it works well.
https://wiki.jenkins-ci.org/display/JENKINS/EnvInject+Plugin
I have been trying to add some environment variables in the Visual Studio 2008 for debugging purpose.
This is because I got this warning:
Warning The following environment variables were not found:
$(DEV_PATH)
$(APPFRAMEWORK_INC)
Here's what I did:
I went to Project > Properties > Configuration Properties > Debugging > Environment
And I have tried adding the following (one by one):
DEV_PATH="\ProjectName\source\"
"DEV_PATH=\ProjectName\source\"
$(DEV_PATH)="\ProjectName\source\"
"$(DEV_PATH)=\ProjectName\source\"
Because this is the path I need to set.
But unfortunately it does not work.
What exactly is the syntax?
As per the link: http://msdn.microsoft.com/en-us/library/ms173406.aspx, it is:
DEV_PATH=\ProjectName\source
But, I need to add multiple such environment variables; so, what must be the separator?
Also, please don't tell me that I can right-click on "My Computer" and modify the environment variables there; I want these environment variables only temporarily for this workspace specifically.
I have written a script that looks like:
set DEV_PATH=\ProjectName\source
set APPFRAMEWORK_INC=\ProjectName\app\framework\inc
And I run the script in a command console before launching Visual Studio.
Hence, the environment variables are temporary, as they are lost as soon as the console and Visual Studio windows are closed.
I have found that this can happen if you have a pending Windows Update. Rebooting seems to fix the problem, as then the Update gets a chance to be applied.