Certain files should be optional when publishing app as self-contained

dotnet / sdk

Core functionality needed to create .NET Core projects, that is shared between Visual Studio and CLI

https://dot.net/core

MIT License

2.66k stars 1.06k forks source link

Certain files should be optional when publishing app as self-contained #27336

Open vitek-karas opened 2 years ago

vitek-karas commented 2 years ago

For example:

dotnet new console
dotnet publish -r win-x64

The output directory will contain files like:

createdump.exe - only useful when trying to create a managed dump of the app's process
clrgc.dll - only useful when wanting to use different GC for the app (otherwise the default GC is part of coreclr.dll)
msquic.dll - only useful when using HTTP3 functionality
mscordaccore* and mscoredbi* - only useful for debugging
... possibly others

Currently there's no way to tell the SDK to exclude some of these. Even with trimming turned on, some of these files are still there (and not used).

We should reconsider the list of files included in self-contained apps by default and if it would make sense to provide options to either opt-in or opt-out for some of them.

/cc @richlander

vitek-karas commented 2 years ago

See https://github.com/dotnet/runtime/issues/43716 for an example of customer report on this.

baronfel commented 2 years ago

This sounds reasonable, but we'd need a more concrete proposal from the owners of these files - are there logical groups that would be turned off as a whole, for example?

guboi commented 1 year ago

Do I understand that createdump.exe will be signed and packaged with apps by default? This could be a significant security concern.

KalleOlaviNiemitalo commented 1 year ago

Does this issue cover the inclusion of unmanaged WPF DLLs in an app that uses Windows Forms but not WPF?

vitek-karas commented 1 year ago

Do I understand that createdump.exe will be signed and packaged with apps by default? This could be a significant security concern.

@tommcdon could you please comment on this?

Does this issue cover the inclusion of unmanaged WPF DLLs in an app that uses Windows Forms but not WPF?

Probably the better place for this discussions is https://github.com/dotnet/winforms/issues/3723

It's not part of this issue - this issue is about files which are included because some features of the runtime or developer experience make use of them. Mostly there's no way to tell if they are needed by just looking at the code of the app (this is sort of not true for msquic but it depends on the scenario).

Inclusion of WPF dlls in winform apps is mainly a problem for trimming which would require two things:

Support trimming of winform apps - https://github.com/dotnet/winforms/issues/4649
Design and implement some solution so that trimmer can remove native libraries (can't find the tracking issue for that, but it's a well known problem)

There's one more option - omit WPF dlls (even the managed ones) if UseWPF is not set. I don't know enough about the WPF SDK integration to tell if this can be breaking for some apps which use WPF classes without UseWPF today.

NCLnclNCL commented 1 year ago

yes

lonix1 commented 1 year ago

I am getting the crashdump executable, even for a normal publish (i.e. not self-contained), on linux.

env: .net7, docker, linux