Currently, our builds are pretty heavy: for example, size of unpacked "self-contained" variant of Praefectus for Windows is about 71 MiB (and about 30 MiB if zipped with "Ultra" compression level).
One easy way to significantly decrease the package size is to publish the binaries trimmed by dotnet linker (also known as Mono linker). To do that, all we'll need is to add /p:PublishTrimmed=true to our publish command. In my experiment, dotnet linker have decreased the unpacked application size to 30 MiB (16 MiB zipped), which is great.
It comes at a price though. Dotnet linker has its constraints, and it, by specification, may make mistakes (i.e. remove the code that is accessed at runtime, causing runtime errors when this code is called), because some of the classes/methods may be accessed in unusual way (with reflection and such). There's additional configuration that should be applied to dotnet linker in such cases.
The common recommendation for such case is to perform integration testing of resulting binaries: if these integration tests pass, then it means the binaries are good. That means, this task depends on integration test availability; we cannot publish trimmed binaries until we're sure they work well.
Good news are if we'll have the integration tests, this unblocks other significant improvements we may do with our publishing process: we may use any AOT engine, such as CoreRT, or even rewrite Praefectus in any programming language that does unit testing differently, and we'll still be able to verify the resulting binaries using our integration test suite.
Depends on:
[x] #20 (because we need to set up the integration test suite first)
Currently, our builds are pretty heavy: for example, size of unpacked "self-contained" variant of Praefectus for Windows is about 71 MiB (and about 30 MiB if zipped with "Ultra" compression level).
One easy way to significantly decrease the package size is to publish the binaries trimmed by dotnet linker (also known as Mono linker). To do that, all we'll need is to add
/p:PublishTrimmed=trueto our publish command. In my experiment, dotnet linker have decreased the unpacked application size to 30 MiB (16 MiB zipped), which is great.It comes at a price though. Dotnet linker has its constraints, and it, by specification, may make mistakes (i.e. remove the code that is accessed at runtime, causing runtime errors when this code is called), because some of the classes/methods may be accessed in unusual way (with reflection and such). There's additional configuration that should be applied to dotnet linker in such cases.
The common recommendation for such case is to perform integration testing of resulting binaries: if these integration tests pass, then it means the binaries are good. That means, this task depends on integration test availability; we cannot publish trimmed binaries until we're sure they work well.
Good news are if we'll have the integration tests, this unblocks other significant improvements we may do with our publishing process: we may use any AOT engine, such as CoreRT, or even rewrite Praefectus in any programming language that does unit testing differently, and we'll still be able to verify the resulting binaries using our integration test suite.
Depends on: