ayan.poddar/eShopOnContainers
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity

Updated 03. Setting the eShopOnContainers solution up in a Windows CLI environment (dotnet CLI, Docker CLI and VS Code) (markdown)

Cesar De la Torre 2017-10-27 18:02:42 -07:00
parent 867b23e7f1
commit 82d0a81a6e
1 changed files with 1 additions and 1 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
03.-Setting-the-eShopOnContainers-solution-up-in-a-Windows-CLI-environment-(dotnet-CLI,-Docker-CLI-and-VS-Code).md

@ -127,7 +127,7 @@ If you have any issue here, read the [Setting the Web SPA application up](https:
# Option A. Approach building bits from a Linux build-container instead of the local Windows dev-machine
**IMPORTANT NOTE (as of Oct. 2017):** This is the simplest way to do it from the CLI, but if you are getting errors related to the CLI logger which happens ramdomly due to a race condition, a [bug in .NET CLI when running "dotnet publish" within a container](https://github.com/Microsoft/msbuild/issues/2153#issuecomment-305375162), please, then follow the OPTION B explained below, which is building the app's .NET binaries in the local Windows machine, instead of from a Linux build-container.
*IMPORTANT NOTE (as of Oct. 2017):* This is the simplest way to do it from the CLI, but if you are getting errors related to the CLI logger which happens ramdomly due to a race condition, a [bug in .NET CLI when running "dotnet publish" within a container](https://github.com/Microsoft/msbuild/issues/2153#issuecomment-305375162), please, then follow the OPTION B explained below, which is building the app's .NET binaries in the local Windows machine, instead of from a Linux build-container.
---
The recommended approach is to build the .NET bits and Docker images by using an special build container/image that should be used either from the CLI or your CI/CD pipeline. Doing that way you'll make sure that what you run and test locally is also built the same way by your CI/CD pipleine (having the same dependencies available within the build container, etc.).