The current NuGet package (version 3.1.3) weights 115 MB.

Commit a932934 added support for Linux/arm64. Creating a new NuGet package with MongoDB 5.1.1 and the database tools 100.5.1 now weights 146 MB. It would weight 180 MB without stripping binaries (introduced in 67dd1e9).

I think this starts to become problematic. 146 MB is a lot, even by todays standards. Also, 4 different platforms/architectures are provided by the package but only one will be usable. For example, the x64 ELF mongod binary will only run on Linux, it is a waste to download it on macOS and Windows.

I can think of two solutions to this problem.

1. Split the Mongo2Go package like SkiaSharp is doing with SkiaSharp.NativeAssets.Linux, SkiaSharp.NativeAssets.macOS and SkiaSharp.NativeAssets.Win32. We could keep the core Mongo2Go package for the core functionality and provide 4 packages for the native assets (i.e. binary executables): Mongo2Go.Native.Linux.arm64, Mongo2Go.Native.Linux.x64, Mongo2Go.Native.macOS.arm64 and Mongo2Go.Native.Windows.x64.

2. Do not provide the binary executable as part of the NuGet package but download them on demand instead.

My preference goes to the second option because it solves the package size issue and it even enables the consumer to choose the MongoDB version it wants at runtime. This would also untie the MongoDB version from the Mongo2Go version. The first option would still require to produce new NuGet package for new MongoDB versions whereas the second option completely solves this issue.

I have already started working on a branch (split-downloader-cli_parts) to re-use the code that was written for the MongoDownloader tool so that it becomes usable directly from Mongo2Go. The idea is for the consumer to be able to specify which version of MongoDB it wants using the familiar NuGet version range syntax. I have already implemented the best version match in my branch (leveraging the NuGet.Versioning package).