-
Notifications
You must be signed in to change notification settings - Fork 127
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
[Question] Does trim analyzer emit warnings for the inaccessible code? #3239
Comments
The linker should produce a warning that points at the reflection code, assuming the reflection code isn't written in a way that can be statically analyzed (with Blazor wasm disables trim warnings out of the box (see dotnet/aspnetcore#44845). To see whether the linker is producing such a warning you can set |
The WTF of the day. Thanks. |
The trimmer will not warn about "unused" code - that happens all the time. The trimmer should produce a warning at the point where the library is trying to access this code via reflection. In your case I would expect warnings from the refit library, but not from other libraries which are just "using it". There's nothing wrong with having "dead" code in your app - if it's not needed at runtime, nothing cares. The problem is if the app needs to access things which the trimmer can't figure out. And so the trimmer "thinks" it's dead code, but the app is trying to use it. The only way to correctly detect this is to look at the place where the app is "looking" for this code. |
@voroninp I tried adding a PackageReference to Refit, and I see this warning in the publish output (not in the build output):
You can show more details by setting
|
@sbomer , yes, it looks like I am mistakenly awaiting trim warnings also on build, not only on publish. |
FWIW, trimmability of refit is tracked in reactiveui/refit#1389. It is not currently compatible with trimming. |
@sbomer , is it possible to trigger full analysis as a step of build process without publishing? |
No, the Roslyn analyzer that runs during build doesn't have insight into the implementation of referenced assemblies, and ILLink is set up to run during publish because that's the point at which all implementation assemblies become available to the toolchain. |
I want to share data contracts between backend and frontend, including API definition.
I use Refit and I see it generates private classes which are not used in assembly anywhere. These classes are instantiated with reflection. So there's no chance they are going to be ever rooted by static code.
When I set data contract library as trim compatible my BlazorWasm application fails to start because Refit cannot find the generated implementation. Obviously 🤣
Should not linker produce a warning when it detects an isolated set of private dependencies which are 100% will be inaccessible by any non-reflection code?
The text was updated successfully, but these errors were encountered: