Why createdump.exe is needed to do "dotnet publish"?

[mingtong]

I am trying to publish a .NET 5 trimmed App(upgrading from .NET Core 3.1), with the command
"dotnet publish -c Release --force -r win-x86 --self-contained true "xxxcsproj" /p:PublishTrimmed=true"
I found the following DLLs are needed.

• System.Formats.Asn1.dll
• Microsoft.Windows.SDK.NET.dll
• WinRT.Runtime.dll
• api-ms-win-core-console-l1-2-0.dll
• createdump.exe

But I am quite confused why createdump.exe is needed to run?
Is it for .NET 5 RC2 to collect dump file and will not be needed in Release version?

And, is there a way to reduce the size of "Microsoft.Windows.SDK.NET.dll", it's nearly 30MB.

[Dotnet-GitSync-Bot]

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke
See info in area-owners.md if you want to be subscribed.

[vitek-karas]

@sbomer Do you remember the rules around native library trimming in self-contained apps? Did createdump.exe slipped through?

As for Microsoft.Windows.SDK.NET.dll that's basically all of WinUI APIs I think (not an expert in this area). PublishTrimmed=true will only remove entire assemblies, it does not remove parts of assemblies. It can be asked to do so, but it's very likely to break the application unless the assemblies in question are prepared for it. I don't think WinUI has done any work to be trim-friendly, so I would not try to do it (very likely to break the app).
@AaronRobinsonMSFT might know a bit more about the WinUI side of things.

Please note that trimming is still an experimental feature. Be sure to thoroughly test the trimmed app.

[AaronRobinsonMSFT]

Microsoft.Windows.SDK.NET.dll is for WinUI and other WinRT scenarios. We did not start investigating support for trimming though. Attempting that is possible but I agree with @vitek-karas that the probability is low it will be successful.

/cc @Scottj1s

[sbomer]

We don't remove native libraries at the moment. The OOB package had some support for it but we didn't productize it. There's at least one existing issue about it at dotnet/linker#2853. IIRC one of the open questions was how to handle the windows native compat shims - they may or may not be required, depending on the target windows version.

[mingtong]

We don't remove native libraries at the moment. The OOB package had some support for it but we didn't productize it. There's at least one existing issue about it at dotnet/linker#2853. IIRC one of the open questions was how to handle the windows native compat shims - they may or may not be required, depending on the target windows version.

Sorry, I don't quite clear for "createdump.exe“, is it expected at this moment?

[vitek-karas]

Sorry for the confusion.

Short version: yes, it is expected at this moment. I would think you can safely remove the file if you really want to - it might break some dump debugging scenarios, but it should not be needed to run the app itself.

The trimming process splits the files in the output into 3 categories:

• Managed assemblies (which may be trimmed)
• Native libraries - in reality this is all of native executables, so createdump.exe falls into this category
• Other - typically data files and so on

As noted above there has been some history around trying to remove some of the files in the native libraries category when trimming. Apparently none of the prototypes made it into the product, so we intentionally leave the native binaries as is.

[mingtong]

Sorry for the confusion.

Short version: yes, it is expected at this moment. I would think you can safely remove the file if you really want to - it might break some dump debugging scenarios, but it should not be needed to run the app itself.

The trimming process splits the files in the output into 3 categories:

• Managed assemblies (which may be trimmed)
• Native libraries - in reality this is all of native executables, so createdump.exe falls into this category
• Other - typically data files and so on

As noted above there has been some history around trying to remove some of the files in the native libraries category when trimming. Apparently none of the prototypes made it into the product, so we intentionally leave the native binaries as is.

Thank you, it's clear for the categories.

Actually, the "createdump.exe" is needed to start my service(my App).
If I manually delete the "createdump.exe" in the running folder, and restart my service, it will report the following error:

Message: Error:
An assembly specified in the application dependencies manifest (xxx.deps.json) was not found:
package: 'runtimepack.Microsoft.NETCore.App.Runtime.win-x86', version: '5.0.0-rc.2.20475.5'
path: 'createdump.exe'

[vitek-karas]

You're right - it is still needed. This is unfortunate - the app actually doesn't need the file for anything, but it's listed as "being part of the app" and the host checks that everything which is part of the app is present, so it fails.

[mingtong]

You're right - it is still needed. This is unfortunate - the app actually doesn't need the file for anything, but it's listed as "being part of the app" and the host checks that everything which is part of the app is present, so it fails.

OK, the last question is, will it be removed in .NET 5 release? or .NET 6?
I found somebody put it in the .NET 6.0 milestone.

p.s. after answer this, you can choose to CLOSE or any other actions for this issue.

[agocke]

Yeah I put it in the 6.0 milestone because I don't think we should require it in the deps.json if it's unused. It may still be useful to copy to the output, but if users should be able to remove it if they want

[vadi2]

It's a particular problem for Squirrel users distributing .NET 5 apps as the two .exe's confuse the installer, and there's no way to mark one of them as Squirrel-aware. As a workaround, this does the job:

jq "del(..|.\"createdump.exe\"?)" publish/App.deps.json
+ delete createdump.exe

[mungojam]

@vadi2 if we can get Squirrel/Squirrel.Windows#1692 merged, then there will be a better solution to the squirrel issue

[ComtelJeremy]

It's a particular problem for Squirrel users distributing .NET 5 apps as the two .exe's confuse the installer, and there's no way to mark one of them as Squirrel-aware. As a workaround, this does the job:

jq "del(..|.\"createdump.exe\"?)" publish/App.deps.json

• delete createdump.exe

@vadi2 Just wondering, did you set this up as a MSBuild step? I have my Squirrel releasify running as a PostBuild step. Any suggestions?

[vadi2]

Sorry, I just did it as a separate github actions step. MSBuild does not look pleasant to be messing with.

[ComtelJeremy]

Thanks for replying. I'll probably just include jq in my Scripts folder and call it as a PS script, or something. Hopefully that will let us release with Squirrel, as that is our hold on migrating to Core.

[bitbonk]

@vadi2 @agocke Can you elaborate on in what way it may be useful to copy that file to the output? What "dump debugging scenarios" are depending on the existence of createdump.exe?

I am asking because, we built our own little executable that the .NET application itself will launch to create a dump whenever there is an unhandled exception in the app. Maybe we can get rid of our executable and use createdump.exe now? It didn't exist when our app was netcoreapp3.1 but we upgraded to net6.0-windows and now we get createdump.exe in our build output.

[agocke]

See https://docs.microsoft.com/en-us/dotnet/core/diagnostics/debug-linux-dumps for info on createdump. It's primarily for creating managed dumps on Linux, but can also work on Windows.

[agocke]

Alternatively, one way to remove createdump is to publish as a single file with PublishSingleFile=true. See https://docs.microsoft.com/en-us/dotnet/core/deploying/single-file for details. Notably, if you have native libraries, you'll need an extra IncludeNativeLibrariesForSelfExtract

[MrM40]

Can I prevent it to be created in .NET 6?
Creating a single file is a bad solution in many cases.

It's my experience that in 99.9999% of all crash cases in the real world these dump files will never be used anyway, just bloating your system and steel time, CPU and ram when being created. Not saying they cannot be useful, it's just EXTREMELY rare they will be investigated by anyone.
So having it created as default is a bad decision in my view.
IF someone some day, 1 out of a million, need it, then it could be enabled by an option but only then.

[vitek-karas]

There's no simple way to prevent this. The simplest is probably to add a custom post-build target and just delete the file from the output.

[MrM40]

Yea, that's what I did, but what a waste of time.

<Target Name="PostPublich" AfterTargets="Publish">
<Exec Command="del PathToFile" />
</Target>

[vitek-karas]

I created dotnet/sdk#27336 to start the discussion as the problem is bigger (more files) and really lies in the SDK (at least the design part, some of the implementation might be in runtime, but that's not important for the feature request).