Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

.Net Core ENTRYPOINT is not using AssemblyName for .dll reference #1583

Closed
jmreiche opened this issue Jan 24, 2020 · 2 comments · Fixed by #1723
Closed

.Net Core ENTRYPOINT is not using AssemblyName for .dll reference #1583

jmreiche opened this issue Jan 24, 2020 · 2 comments · Fixed by #1723
Assignees
Milestone

Comments

@jmreiche
Copy link

When using the otherwise brilliant "Add Docker Files To Workspace.." feature it seems like the code to generate the ENTRYPOINT at the end of the Dockerfile uses the name of the Project instead of the AssemblyName from inside the .csproj file.

This means that if you have another AssemblyName specified inside the .csproj then the reference for ENTRYPOINT will point to an incorrect .dll name.

This will give a cryptic error message when trying to run the Docker image:

It was not possible to find any installed .NET Core SDKs
Did you mean to run .NET Core SDK commands? Install a .NET Core SDK from:
https://aka.ms/dotnet-download

In my case the line generated was:

ENTRYPOINT ["dotnet", "Physio.Server.WebApi.dll"]

But should have been:

ENTRYPOINT ["dotnet", "Habitlab.Physio.Server.WebApi.dll"]

As that is what I have specified in AssemblyName and RooNameSpace for that matter.

@philliphoff
Copy link
Contributor

@jmreiche You're right, the scaffolding logic makes the assumption that the assembly name matches the project file name when generating the Dockerfile. Interestingly, we don't make that assumption when debugging that same project (where we extract the evaluated TargetOutputFilename from the project file). (Note that the scaffolding logic was written long before the debugging logic and likely just didn't take that scenario into account.) Given that, it should be straightforward to fix.

@jmreiche
Copy link
Author

Super. Thanks a lot for the rapid feedback! I could not imagine it being a difficult fix either. Just annoying for the few people who encounter it, as the error received from Docker is cryptic.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants