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

Consider disabling UseAppHost in generated Dockerfiles #321

Closed
mthalman opened this issue Jan 10, 2022 · 4 comments
Closed

Consider disabling UseAppHost in generated Dockerfiles #321

mthalman opened this issue Jan 10, 2022 · 4 comments
Assignees

Comments

@mthalman
Copy link
Member

mthalman commented Jan 10, 2022

The Dockerfiles generated by VS include the following line:

RUN dotnet publish "WebApplication.csproj" -c Release -o /app/publish

This ends up outputting both a WebApplication executable and a WebApplication.dll library file in the output directory. Either file can be used to execute the app. The executable can be executed directly while the DLL requires the use of the .NET CLI (dotnet WebApplication.dll). From an image size perspective, it seems wasteful to include both files in the output. Only one of them is actually needed in order to execute the app. The Dockerfile is configured to only make use of the DLL:

ENTRYPOINT ["dotnet", "WebApplication31.dll"]

So it seems reasonable to simply not include the executable in the output.

By using the UseAppHost property, the publish logic can be configured to not include the executable in the output.

I propose that the Dockerfiles generated by the tools set this property by default:

RUN dotnet publish "WebApplication.csproj" -c Release -o /app/publish /p:UseAppHost=false
@bwateratmsft
Copy link
Contributor

This is probably a good thing to do in vscode-docker as well.

@mthalman mthalman changed the title Consider setting UseAppHost in generated Dockerfiles Consider disabling UseAppHost in generated Dockerfiles Jan 10, 2022
@dbreshears
Copy link
Member

Yep. this makes sense to do. I've added an item on the VS tooling backlog

@devopg
Copy link

devopg commented Jan 30, 2022

yes do this thing sync with default as local pc build.

dotnet/dotnet-docker#3389

@dbreshears
Copy link
Member

This was completed, closing

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

No branches or pull requests

5 participants