[C#] .NET DLLs too Large after Export

[hamster5295]

Godot Version

v4.6.1.stable.mono.official [14d19694e]

Question

TL;DR

The .NET related DLL files are too large after export, and I wonder how to optimize.

Details

Currently I’ve almost finished a casual game with C#.

I was expecting it small in size when exported as there are neither heavy assets nor complicated scenes and architecture, but it came out with ~175MB in size for a Windows Release (unzipped, zipped ~75MB).

I created an empty project to test it out, and found that the .NET Assemblies are taking up much space. Here is my empty project with only an Main.cscreated by Godot’s dialog without any modifications:

This project was exported with the default Windows export config without Debug symbols, and here’s what I got:

The size-test-4.exe is large though, but it can be further optimized through customizing export templetes. But the *.dll files, which are likely .NET assembly related stuffs, are taking up to ~76MB, almost half the size of the artifact, and currently I haven’t found any docs on how to deal with them.

In comparison, I created another empty project with Godot 4.6.1 and export without creating the C# script, and the *.dll stuffs were gone completely.

Back to Godot 3.6 when mono was used, the .NET related files were moderate, as exporting an empty project with a default Main.cs would create an artifact like this:

Only 2.1M of space was taken by .NET, which indicates there’re further space for optimization in Godot4.

I’ve searched the Godot repo but haven’t found any related issues. If you know about any approach to reduce the size of them or I missed something, please let me know.
If there’s no further information, I’ll consider opening an issue about it.

Thank you for your help in advance!

[OriginalBadBoy]

Its not like you are trying to squeeze this onto a floppy disk. 175MB by today’s standards isn’t exactly big. Honestly, this is probably not worth the effort.

If you are creating a 2D game for example you could probably make is smaller by removing 3D altogether:

Optimizing a build for size — Godot Engine (stable) documentation in English

[hamster5295]

@OriginalBadBoy

175MB by today’s standards isn’t exactly big.

Yes indeed, I was just wondering if I missed something that could avoid this issue. If not, I belive this is a missing feature of the Engine.

Even though 175MB is affordable these days, I don’t find it reasonable for a simple pong game to be of size like this.

---

@OriginalBadBoy

Honestly, this is probably not worth the effort.

That’s right, and I’m likely to ship my game with that size.

But I’m also willing to look into this issue and help out, and I would be happy if this issue can be finally addressed, benefiting everyone further on

[tibaverus]

@hamster5295

~175MB in size for a Windows Release

I think this is a bit misleading. If you export the zip file, which is what you should be giving out to your players anyway or uploading to places like itch, the size is only around 75mb, which is quite reasonable. Unity has about the same size when exported.

[GamesStudioTwo]

Sorry to butt in I was worried about the size when I stated but noticed in his tree all the .dll dose godot package the windows dll in the export and that’s why its so big. if so that fantastic because I got fed up writing in cpp dot net then when you put it on another machine don’t work because is missing dll. Bla bla bla even though you say add all the dlls from my system or you now got to install dot net. Because its missing, is that why its so big because that solves all the problems of game not running or incompatible dll versions? I hope it is.

[OriginalBadBoy]

Or if adding to an MSI installer package for example, that would also compress to a reasonable amount.

[tibaverus]

This is not necessary or even recommended for most modern platforms such as Itch or Steam.

[hamster5295]

@tibaverus

I think this is a bit misleading. If you export the zip file, which is what you should be giving out to your players anyway or uploading to places like itch, the size is only around 75mb

You’re right, I’ll update my post. Sorry!

@tibaverus

Unity has about the same size when exported.

But this might not be the exact case.
Here’s the tree of an almost-empty Unity project exported with Unity 2022.3.42f1 which contains nothing but some common C# scripts:

It seems that Unity reaches ~75MB without being zipped, while Godot has to zip to reach this level.

[hamster5295]

And guys I think we’re in the wrong focus of discussion.

Compressing the exported project can save up much space indeed, but from the comparison between Godot 3 and Godot 4, it seems that exported projects with .NET module ARE ABLE TO RUN without so many DLL dependencies.

That means ONE of the cases below:

1. The new .NET runtime is to blame (Godot 3 used Mono and has a small exported size)
2. Godot 4 can do better when exporting projects with .NET module enabled
3. I’ve missed something important that lead to Godot exporting unnecessary DLL files

Now I think 3 is much unlikely, and if 2 is the case, I’d like to open up a issue for better tracking and solving this problem

[Varonex]

Isn’t it normal that all the dlls are within the package? It would otherwise require all the users who are playing your game to have those DLLs installed, which may not be the case for most of them

I’m no expert, but that’s the reason why Java can only be ran if you at least have a JRE

Assuming you don’t bundle all System.*.dll files, your app would require those to be installed directly on the host, at the proper version of course. That said, users would have to go through a framework installation process to make your app work, and they may not want to do so because this process is an extra step.
There’s also a versioning issue. If the user has dotnet 8 and you used dotnet 9 features, they would have to upgrade it, which can be seen as a hassle as well.
That’s how Minecraft works, during the older days you sometimes had to get the JRE on your machine depending on the usage. Of course, nowadays openjdk is directly downloaded, so this step is not noticeable. Additionally, this jdk is installed whether or not you have another one already on your machine. So it actually potentially duplicate a jdk if you already have the same installed (memory duplication is mentioned further down).

Exporting your game with bundled dlls can seem as expensive. If you install n games with Godot C#, all the n games will have their own copy of those dlls, and if the n games used the same godot version AND same dotnet version aswell, there’s only really just your game’s classes that will vary. That takes storage for nothing, but is a huge boost in terms of ease of use.

Eventually, usually game assets are the main reason why games tend to be memory hungry, not the system side of things. Of course it’s not always true, especially in pixel art games with assets that can take only a few bytes/kilobytes to store.

[tibaverus]

@hamster5295

I’ve missed something important that lead to Godot exporting unnecessary DLL files

As far as I know, none of those DLLs are “unnecessary”. The truth is, if you export your game without C# support, with an almost completely empty project, uncompressed, with no modifications to the export template, it’ll still be around 100MB or so after you unpack the files.

As much as I hate to admit it, C# is very much a second class citizen in the Godot world even now. So you will see a lot of gotchas while using it. This is coming from someone who almost exclusively uses C# with Godot.

You CAN decrease the size a lot by removing modules that you don’t need, such as the 3D module if you made a 2D only game, or use small optimizations like that, see:

How to Minify Godot's Build Size (93MB -> 6.4MB exe)

Optimizing a build for size

[hamster5295]

@tibaverus @Varonex Thank you for your replies!

@tibaverus

You CAN decrease the size a lot by removing modules that you don’t need, such as the 3D module if you made a 2D only game, or use small optimizations like that

Currently this is indeed the Best Solution to the size problem.

However, none of the answers explain Why Godot 3 with Mono can get down to ~2.1MB in dependency size.

I looked a bit further on into it, and found that Mono can actually function as a .NET runtime with 3MB or less:

How to make a smaller Mono install | Mono

Which explains how Godot 3 could be as small as that.

The .NET8 itself is large, and using the PublishTrimmed flag:

// In .csproj
<PropertyGroup>
    <PublishTrimmed>true</PublishTrimmed>
</PropertyGroup>

doesn’t work for Godot 4, leading to this error message when exporting:

Which seems to be a issue related to .NET8 itself.

In conclusion, currently it seems impossible to get rid of the .NET dependencies, and the best thing we can do is as @tibaverus posted:

Optimizing a build for size

How to Minify Godot's Build Size (93MB -> 6.4MB exe)

[tibaverus]

@hamster5295

However, none of the answers explain Why Godot 3 with Mono can get down to ~2.1MB in dependency size.

As far as I know, that’s because mono is / was a lightweight .NET re-implementation, but godot doesn’t use mono anymore because its been obsolete for the most part, it’s still called Mono for historical reasons, but the “mono” version of Godot has nothing to do with mono anymore.

[OriginalBadBoy]

@tibaverus

This is not necessary or even recommended for most modern platforms such as Itch or Steam

True but if you are using something like GoG as well you would need some sort of packager. But yeah MSI these days for games is probably overkill if the platform is only Steam for example.