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

What is the current protocol in deciding what TFM to use for a project? #4591

Closed
Yun-Ting opened this issue Jun 14, 2023 · 2 comments
Closed
Labels
question Further information is requested

Comments

@Yun-Ting
Copy link
Contributor

Yun-Ting commented Jun 14, 2023

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.)

@Yun-Ting Yun-Ting added the question Further information is requested label Jun 14, 2023
@vitek-karas
Copy link
Contributor

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.

@eerhardt
Copy link
Contributor

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.

You can read about the pros and cons at:

@ViktorHofer, do you have any suggestions in this area for other library authors? In my point of view, the advantages clearly outweigh the disadvantages.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
question Further information is requested
Projects
None yet
Development

No branches or pull requests

3 participants