kekyo
commented
1 year ago Thank you for your suggestion. However, we will not make this correction. There is a reason why we are including these tfm (ignoring MS best practices).
It is because when package dependencies become complex, they can cause errors that are difficult for users to understand. This is due to the fact that when there are multiple NuGet packages, not only FlashCap, that contain dependent libraries, and a diamond dependency graph (similar to diamond inheritance in C++ multiple inheritance) occurs in the dependent versions of tfm, it is difficult to control which tfm you want to use, and analyzing the diamond dependency graph is not easy either. This is the reason why it is not easy to control the tfm we want to use and also to analyze it.
In my past experience as an engineer, this type of problem has been very frustrating. FlashCap has put a lot of effort into achieving the task of eliminating dependent libraries, which is the same kind of problem as tfm.
Since I do not have a complete solution to this problem, I am going with a very simple strategy. That is, include as many tfm's as possible in the package based on the fact that NuGet will give preference to exact match tfm's when guessing the best version.
Of course, if we included all the tfms from the net35 set, it would be much larger.
So we adjust the package to include the tfm before and after the tfm that is supposed to undergo major changes.
For example, net40 adds TPL, net45 adds exception capture support to TPL, net461 is compatible with netstandard2.0, etc...
As such, FlashCap was to include many tfm. (Actually, it is not only FlashCap, but other projects of mine as well.) Note that while the package size will indeed be reduced, the NuGet package will only be downloaded the first time, and the FlashCap assembly included in our application is only one version of the required tfm. We do not expect a large impact during development, nor a large impact on deployment.
According to this document, reduce TFM overlaps.