Add property to include libmscordbi.so, libmscordaccore.so, and createdump when publishing self-contained, single file applications #112584
Description
Is your feature request related to a problem? Please describe.
The general problem: I am trying to use dotnet-dump and a debugger (e.g. vsdbg but this holds for netcoredbg too) targeting a self-contained, single file application. However, dotnet-dump and vsdbg both require specific runtime files in the directory of the target process's single file in order to function, but those files are not included in a single-file publish.
More specifically, I was looking to use the diagnostic tools (all of them, including dotnet-dump) and the debugger in an ephemeral container in Kubernetes to target a .NET application which was running in a container built off the new chiseled images. I have the ephemeral container with these tools working now, but I need to copy in three runtime files (libmscordbi.so and libmscordaccore.so for vsdbg and createdump for dotnet-dump) to the target image at build-time after the publish completes in order for the tools to be able to function (I also have to symlink the diagnostic socket and CLR pipes, run as the target process user for any of the diagnostic tools, and have the SYS_PTRACE capability for dotnet-dump and vsdbg to work - noting for completeness, though I don't think it affects this request).
If createdump is not present, I get an error Write dump failed - HRESULT: 0x00000000. for dotnet-dump.
If the libmscordbi.so and libmscordaccore.so files are not present, vsdbg will output Unknown error: 0x80131c4f.
From what I can glean, when publishing a self-contained, single file application for linux-x64 on .NET 6.0.26, the runtime files libmscordbo.so, libmscordaccore.so, and createdump are all configured with the DropFromSingleFile property set to true in the microsoft.netcore.app.runtime.linux-x64 package's RuntimeList.xml file. This results in them getting excluded during the ComputeResolvedFilesToPublishList target populating the ResolvedFileToPublish property (with the ResolveRuntimePackAssets target and its eponymous task responsible for reading the RuntimeList.xml file coming in as a dependency of the ComputeResolvedFilesToPublishList target).
In any case, there doesn't seem to be any way to adjust this behavior via MS Build properties at the command line. I could probably add a custom target and modify the ResolvedFileToPublish property to work around this, but it'd be nice if there was a property I could set to opt into including those files when doing a self-contained single file publish rather than have every repository incorporate a new custom target..
Describe the solution you'd like
The approach I was thinking was adding a separate property to the RuntimeList.xml file, something like IsDiagnosticSupport. That could be used to flag files which we know are needed for the diagnostic tools. The ResolveRuntimePackAssets task would be updated to understand that, and then ComputeResolvedFilesToPublishList could consider whether another property, IncludeDiagnosticSupportNativeFiles, is set and then add any files from the runtime list (ResolvePackAsset property) which have IsDiagnosticSupport set to true back to the ResolvedFileToPublish property with their ExcludeFromSingleFile property set to true (so they are included in the publish but not in the single file itself).
I'd be fine with most any solution that lets me control this at the command line using one or more properties.
Additional context
I spot checked the .NET 8.0.1 linux-x64 runtime package, and this looks to still be the case.
I wasn't sure whether to file this to the Runtime, who presumably own the NuGet package and the RuntimeList.xml file, or here since this repo owns the target which owns the task and targets and consumes the property value.