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

[vitek-karas]

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]

See dotnet/runtime#43716 for an example of customer report on this.

[baronfel]

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]

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

[KalleOlaviNiemitalo]

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

[vitek-karas]

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 dotnet/winforms#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 - Epic - Make WinForms trim compatible winforms#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]

yes

[lonix1]

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

env: .net7, docker, linux