You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Code analyzers are producing errors and recommending fixes that aren't compatible with all my target frameworks, and I have yet to find a good solution. I am creating a plugin for an external application that uses a different runtime based on version. I need to write code that is both conditional on the APIs for the version of the application and runtime target.
The issue with my setup is that when I switch from net48 to a net8.0 configurations analyzers are recommending me changes that is incompatible with net48. It doesn't make much sense for me to add <TargetFrameworks>net48;net8.0-windows</TargetFrameworks> as it doubles build times (something I may be able to live with if there is no better solution).
I'm wondering if there is someway to specify net48;net8.0-windows but only ever build one of these based on configuration. Or whether VS can scan for TargetFramework based on conditions and provide analyzers that are compatible with both. For simplicity if I can write the code that is compatible with net48 with reasonable performance I would prefer this vs branching logic based on framework.
User Impact
Analyzers giving incorrect code fixes leading to a less than ideal solution in which I either need to
a) having to add them to a list of ignores every time I encounter 1
b) reduce analyzer mode to try prevent this behaviour
The text was updated successfully, but these errors were encountered:
Thanks for taking the time to share this. Currently, language services (which drive analyzers) require visibility into all the target frameworks you're using in order to avoid making recommendations that only work in a subset of those targets. The set of target frameworks loaded is controlled by <TargetFrameworks>.
Your concern about building more than you want is valid. I think that's similar to the request here: #3323
Unfortunately there's no way currently to constrain build to a subset of target frameworks.
How much overhead does building all target frameworks cause in your solution?
Yes, I had investigated using this solution. We use IL-Repack so build times can be long (needed for net framework), however, I've since come up with another solution to alleviate this.
We have people new to .net with limited coding experience so I wanted it set up in a way that is most friendly to a beginner (the build process is already complex enough).
But I think you're right, maybe this is my only option and they'll just need to be aware of choosing the right configuration/target framework when debugging/running unit tests.
Summary
Code analyzers are producing errors and recommending fixes that aren't compatible with all my target frameworks, and I have yet to find a good solution. I am creating a plugin for an external application that uses a different runtime based on version. I need to write code that is both conditional on the APIs for the version of the application and runtime target.
The issue with my setup is that when I switch from net48 to a net8.0 configurations analyzers are recommending me changes that is incompatible with net48. It doesn't make much sense for me to add
<TargetFrameworks>net48;net8.0-windows</TargetFrameworks>
as it doubles build times (something I may be able to live with if there is no better solution).My setup looks like the following.
I'm wondering if there is someway to specify net48;net8.0-windows but only ever build one of these based on configuration. Or whether VS can scan for TargetFramework based on conditions and provide analyzers that are compatible with both. For simplicity if I can write the code that is compatible with net48 with reasonable performance I would prefer this vs branching logic based on framework.
User Impact
Analyzers giving incorrect code fixes leading to a less than ideal solution in which I either need to
a) having to add them to a list of ignores every time I encounter 1
b) reduce analyzer mode to try prevent this behaviour
The text was updated successfully, but these errors were encountered: