Something interesting I learned about case sensitivity - the hard way

Docker Desktop
,
1

I’m building an app using dotnet core and Visual Studio code. I have simple Dockerization in place for several microservices and have had relatively little problems with my development environment.

However, I recently dealt with an idiosyncrasy related to ENTRYPOINT[] that I thought I might share in case anyone else is dealing with this when composing:

error stuff
Did you mean to run dotnet SDK commands? Please install dotnet SDK from: [URL]

[tldr]

I was baffled by this issue of Docker not being able to run my service, which came up seemingly out of nowhere.

At first I thought I would check the docker images hosted for dotnet core (specifically microsoft/aspnetcore-build:2.0) to see if anything had changed. I didn’t find anything alarming there.

Then I came across a post that talked about case sensitivity and the target file in ENTRYPOINT[].

My service compiles to a dot-notation, PascalCase binary file (SomeFile.Service.dll).

When I changed ENTRYPOINT ["dotnet", "SomeFile.Service.dll"] to ENTRYPOINT ["dotnet", "somefile.service.dll"] everything worked as expected, no error!

I thought this was interesting because:

  1. My app had been working fine for weeks
  2. There hadn’t been any obvious changes to docker images or my environment

Or so I thought.

Not too long ago I had decided to rename some of my files using PascalCase. When I had initialized the project, I had forgotten to do that to begin with. The files that I renamed had already been committed to git and I had to do some magic to untrack, rename, etc.

One file that I had missed was the apps .csproj file. This file remained lowercase as somefile.service.csproj.

So, my .csproj file was somefile.service.csproj (lowercase), but my output assembly was SomeFile.Service.dll. My entry point in dockerfile was ENTRYPOINT ["dotnet", "SomeFile.Service.dll"].

When I used docker-compose up, I would see the error saying it couldn’t find dotnet. (This error sucks, because it actually couldn’t find my assembly. There might be a ticket in for this already).

I went back and made sure that the case used for ENTRYPOINT, .csproj and my assembly all matched and voila!
docker-compose up spun up my service without any errors.

[tldr]

So what I’ve found is that whatever naming convention you use for your .csproj file should match your naming convention for your assemblies. But more importantly, the case used in your ENTRYPOINT[] must match the case used in naming your .csproj file.

2

good catch… but this really isn’t a docker issue… cause u would have had the same problem running that command anywhere…

1 Like
3

I see your point. Running dotnet somefile.dll isn’t part of my workflow, but I think you’re right in that I would have seen the same error just by running the dotnet command.

I discovered the issue while trying to get my container back up and running after refactoring a bunch of dotnet core related work and it wasn’t obvious what was going on from the error message provided by Docker.

It would have been helpful to know that Docker couldn’t find my assembly (which implies possible naming or path issues) as opposed to the generic “do you have dotnet sdk installed” message (which could mean many things, like you’re using the wrong dotnet docker image, the command is bad, etc.).

Not exactly a Docker issue, but their error messaging could be a little more contextual in this case.

4

its not a docker error… that is the point… its a .net application error
docker doesn’t know what the app is supposed to do… it just runs it. all the normal application rules apply