Bundle command does not respect PublishTrimmed setting from csproj file

[connor-lennox]

Hello!

In using GameBundle for a bit now, I've noticed that even when PublishTrimmed is marked as true in the csproj definition, I also have to provide it in the cli args here for it to be respected. This is caused by https://github.com/Ellpeck/GameBundle/blob/main/GameBundle/Program.cs#L75 - I suspect if neither the trim nor AOT flags are set here then the entire line should be removed from the publish command.

I'm not sure if this is intended behavior or not, but if it isn't then I'm more than happy to implement a fix and open a PR. Just let me know.

[Ellpeck]

Hi! This is technically by design since, without essentially "overriding" the AOT/trimming settings, there was no way to disable NetBeauty from being run (which causes errors slash doesn't work, since it's not really supposed to, when running AOT).

At the time, I didn't have the "getting custom properties through MsBuild" system yet though, so maybe that could be used now to detect whether AOT (or trimming) is enabled on project level.

Don't worry about submitting a PR for this though, since I'll probably want to play around with this myself and see if it actually all works well with the project-level detection. Gathering those sorts of settings can be a bit finnicky at times unfortunately :(

[connor-lennox]

Interesting, yes that makes sense. I tested the msbuild checks for trimming (dotnet msbuild -getProperty:PublishTrimmed) and it did return true for my csproj, so I also suspect that would work.

For reference, this is the collection of properties I'm using. All of these are respected (as they aren't overridden) with the exception of PublishTrimmed:

    <PropertyGroup>
        <PublishTrimmed>true</PublishTrimmed>
        <PublishSingleFile>true</PublishSingleFile>
        <PublishSelfContained>true</PublishSelfContained>
        <IncludeNativeLibrariesForSelfExtract>true</IncludeNativeLibrariesForSelfExtract>
    </PropertyGroup>

regarding NetBeauty, I'm actually not passing in the flag to disable it so I'm surprised it's not upset with this configuration. I guess if there's nothing for it to move (this set of properties causes the game to build into a single .exe with nothing else around it), then it must just pass through as a no-op.