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
While exploring different alternatives (#4580 (comment)) to bring in AOT attributes to the repo, I notice currently there is no clear guideline on how to decide the TFM of a project.
Proposal
Make TFMs consistent across different projects; for example, #4370. Retire the TFM when it's out of support across all projects. The engineering overhead I foresee to achieve the goal is insignificant (mainly in maintaining public API docs.)
The text was updated successfully, but these errors were encountered:
I think it's fair to say that most of the problems observed are due to the heavy usage of InternalsVisibleTo which seems to be the norm in this project (I can't comment on why that is). The InternalsVisibleTo make the typical patterns on how to handle various TFMs and multi-targeting much more complex.
For the trim/AOT compatibility effort, it would make things definitely simpler if all project targeted the same set of TFMs. But I don't know the reason why the TFMs are setup the way they are, so I can't really comment on potential disadvantages.
We did a similar effort in dotnet/runtime for our libraries that shipped as NuGet packages. All the libraries have a consistent set of TFMs across the board. For example, for the .NET 8 release, that set is: net8.0;net7.0;net6.0;netstandard2.0;net462. (The set used in OTel would be different - I'm not suggesting to use the same set as dotnet/runtime does). The set changes as TFMs go out of support. Using a consistent set across all libraries in the repo makes working in the repo a lot easier as every library has the same set.
@ViktorHofer, do you have any suggestions in this area for other library authors? In my point of view, the advantages clearly outweigh the disadvantages.
Problem
We currently are relying on the fact of target framework and its implemented .NET standard version when building projects with dependencies and the TFMs of the projects don't match.
This can introduce conflicts in some situations, for example, #4460 (comment)
While exploring different alternatives (#4580 (comment)) to bring in AOT attributes to the repo, I notice currently there is no clear guideline on how to decide the TFM of a project.
Proposal
Make TFMs consistent across different projects; for example, #4370. Retire the TFM when it's out of support across all projects. The engineering overhead I foresee to achieve the goal is insignificant (mainly in maintaining public API docs.)
The text was updated successfully, but these errors were encountered: