Finally my application is ready to be deployed. To make it portable, it needs to be containerized, so I'm working on Dockerfile.

To get a jumpstart, I copied the Dockerfile from https://learn.microsoft.com/en-us/aspnet/core/host-and-deploy/docker/building-net-docker-images?view=aspnetcore-10.0#the-dockerfile. Then I'm thinking to test it locally with the following command:

docker build -t app:latest .

However, it throws few error messages:

error MSB4018: The "ResolvePackageAssets" task failed unexpectedly.

error MSB4018: NuGet.Packaging.Core.PackagingException: Unable to find fallback package folder 'C:\Program Files (x86)\Microsoft Visual Studio\Shared\NuGetPackages'

Ok, it's weird that it's looking for windows path when the image is linux based. I quickly found out that since the COPY step runs locally, it copies the bin and obj directories as well which was generated from my local Windows machine and thus incompatible with the Linux based image.

To prevent that, I tried using .dockerignore file and place it on the same directory as the Dockerfile. Since in dockerignore file, leading and trailing slashes are disregarded, I just need the following content. For more information: https://docs.docker.com/build/concepts/context/#syntax

*/bin
*/obj

Re-building it locally throws yet another error:

error NETSDK1047: Assets file '/source/path/to/app/obj/project.assets.json' doesn't have a target for 'net10.0/linux-x64'. Ensure that restore has run and that you have included 'net10.0' in the TargetFrameworks for your project. You may also need to include 'linux-x64' in your project's RuntimeIdentifiers.

I checked the .csproj file of my application and it doesn't have <RuntimeIdentifier>linux-x64</RuntimeIdentifier>. Probably because my local development machine is Windows. Since I need it to be able to run in both Windows (local) and Linux (remote), I tried the following:

<RuntimeIdentifier>linux-x64;win-x64</RuntimeIdentifier>

Which is supposed to be valid, but the build failed again. This time the message is:

The "HasTrailingSlash" function only accepts a scalar value, but its argument "$(OutputPath)" evaluates to "bin\Debug/net10.0/linux-x64;win-x64/" which is not a scalar value.

Alright, removed <RuntimeIdentifier> tag. On CI/CD pipeline, I'll use the Dockerfile, for local development, I'll just use Visual Studio or dotnet CLI, so I can add --os linux option to dotnet restore step. In the Dockerfile, it becomes:

...
RUN dotnet restore --os linux
...

Then it builds successfully on my local machine. Since bin and obj directories are not tracked by the version control, the CI/CD pipeline won't have to worry about them.