Add an editorconfig option to supress LibraryImport suggestion for blittable PInvokes

[MichalPetryka]

The current LibraryImport analyzer always suggests to convert to it from DllImport, even when it's not necessary due to the signature being blittable. This is especially annoying when multitargeting with older TFMs without LibraryImport.
As discussed on Discord, there should be an option to opt out of this with an editorconfig switch.

cc @jkoritzinsky @tannergooding

[dotnet-policy-service]

Tagging subscribers to this area: @dotnet/interop-contrib
See info in area-owners.md if you want to be subscribed.

[AaronRobinsonMSFT]

even when it's not necessary due to the signature being blittable

This is by design. The source generator does the right thing and there is zero cost from a run time perspective. The goal here was to be consistent in interop code.

This is especially annoying when multitargeting with older TFMs without LibraryImport.

This is fair criticism and some thing I've hit as well.

@jkoritzinsky Should we try to educate the generator on the TFM issue or is creating an escape hatch easier and we can avoid more complexity?

[hamarb123]

Should we try to educate the generator on the TFM issue or is creating an escape hatch easier and we can avoid more complexity?

Educating the generator to be smarter with TFMs would not address all of my problems. Start of (most recent (there may have been more previously, idr)) conversation that caused this issue to be open:

For me, the issue is not just "is there cost at runtime", it's also attribute clutter, unnecessary code churn, suggesting changes when I'd rather just keep using the low-level mechanism (esp. when there's 0 benefit to changing it to me as it's already blittable), forcing me to put partial on everything for no reason, and the aformentioned TFM issue.

For the reasons mentioned in the discord, I think it's reasonable enough for the default to be "just use LibraryImport everywhere" (as that makes it easier to communicate to the majority of users how to do the right thing, without confusing them with too many options for which you need to understand complex things (e.g., whether your signature is blittable or not) to use correctly, etc.); but I think for some of us that are writing blittable bindings the vast majority of the time, this constant suggestion to do something that isn't actually better (and has some actual downsides in some cases) isn't great, when it could just be suggesting it in the cases where it actually improves my code (i.e., those with marshalling - to which my response would probably be "time to remove the marshalling from this 😁" (as it is probably either something old that needs to be updated anyway, or a bug)). I'm happy to have to opt into this mode via editorconfig or msbuild property (preferred to me, as I can then set this mode by default and set SYSLIB1054 to error in my project SDK) somehow.

Currently, I completely ignore SYSLIB1054 as it's not a useful suggestion for most cases in my code. But there are some cases that likely exist where I indeed should be using LibraryImport, or where I could just remove the unnecessary marshalling myself & benefit even more.

Thanks for reading all that 😁

[jkoritzinsky]

Should we try to educate the generator on the TFM issue or is creating an escape hatch easier and we can avoid more complexity?

There's not much we can do to handle the multi-TFM problem at the analyzer level (we can't see that it's a Multi TFM project).

I suggested opening this issue as there's a small number of power users who write almost exclusively blittable bindings but don't want the compile time overhead of LibraryImport for thousands of blittable P/Invokes.

Adding support for an editorconfig option to only suggest the code fix for "marshalling required" P/Invokes is quite cheap and would satisfy our power users with an opt-in option without violating our goal to keep interop usage consistent for our users.

I view this option similarly to the "convert to collection expressions" analyzer and code-fix in Roslyn. The default experience is to always recommend, but there's an option to only recommend in a subset of cases. In their case, the differentiator is due to actual behavioral differences instead of just compile wall-clock-time differences, but the comparison still stands.

[AaronRobinsonMSFT]

There's not much we can do to handle the multi-TFM problem at the analyzer level

Okay, that is unfortunate.

I view this option similarly to the "convert to collection expressions" analyzer and code-fix in Roslyn.

Prior art helps make this concrete, thanks.

I'll mark this as Future, but it is fine if someone wants to handle this in .NET 10. Not sure how much bandwidth the interop team is going to have in .NET 10.