Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support dotnet trimming #1188

Open
ShortDevelopment opened this issue Apr 30, 2023 · 5 comments
Open

Support dotnet trimming #1188

ShortDevelopment opened this issue Apr 30, 2023 · 5 comments

Comments

@ShortDevelopment
Copy link

ShortDevelopment commented Apr 30, 2023

Issue

.NetCore introduced App trimming some time ago to reduce the size of published dotnet apps.
As the c# bond implementation seems to rely on reflection, trimmed applications may break.

Proposal

@chwarr
Copy link
Member

chwarr commented May 10, 2023

Inside of Microsoft, we currently don't need support for app trimming for those apps that use Bond. As such, we have no plans to implement this ourselves. Would you be interested in contributing this?

@ShortDevelopment
Copy link
Author

ShortDevelopment commented May 10, 2023

Sure, why not! I’ve already looked at the code and I was wandering, why the projects are still targeting net4.5 and netstandard1.6 (they should be out of support by now).

It might actually be more desirable to move to roslyn source generator to allow for scenarios without the reflection and dynamic generation that seems to be going on behind the scenes.

This should not only improve (startup) performance but also fix this issue because there would be no dynamic elements that could be trimmed away.

@chwarr
Copy link
Member

chwarr commented May 10, 2023

.NET 4.5 can be dropped and replaced with .NET 4.6.2.

Support for reflection-based serialization can't be completely dropped. There are uses where the object to be serialized isn't known at compile time.

So, I recommend splitting the trimming support from Roslyn-based source generation and tackling them on their own.

Let's let this issue focus on trimming.

@ShortDevelopment
Copy link
Author

Would it be okay to simply target netstandard2.0 instead of net45;net46;netstandard1.3;netstandard1.6?
It should be compatible with all other targets (except net45).
See https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-2-0

@chwarr
Copy link
Member

chwarr commented May 11, 2023

Yes, solely targeting netstandard2.0 looks like it will work now that the floor for .NET Framework can be raised to 4.6.2. Thanks for checking the compatibility table. This will also allow clean up of all(?) the conditional compilation too. (Both the .cs and .csproj files will need to be updated.)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants