-
Notifications
You must be signed in to change notification settings - Fork 780
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
Clean up TFMs for docs #4904
Clean up TFMs for docs #4904
Conversation
docs/trace/stratified-sampling-example/stratified-sampling-example.csproj
Show resolved
Hide resolved
Codecov Report
@@ Coverage Diff @@
## main #4904 +/- ##
=======================================
Coverage 82.93% 82.94%
=======================================
Files 294 294
Lines 12200 12200
=======================================
+ Hits 10118 10119 +1
+ Misses 2082 2081 -1
Flags with carried forward coverage won't be shown. Click here to find out more. |
@@ -2,13 +2,6 @@ | |||
<Import Project=".\Common.props" /> | |||
|
|||
<PropertyGroup> | |||
<!-- OmniSharp/VS Code requires TargetFrameworks to be in descending order for IntelliSense and analysis. --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI - I moved all the TFM info to Common.props
instead of having to separate prod/nonprod, I think having all TFM info in a single place would make it much easier to introduce new runtime version / deprecate old runtime / ensure consistency.
Pros: in most cases I imagine these TFMs to be updated when we introduce/remove a new target framework, having these in one place is just easier to maintain/read.
Cons: a little bit naming pollution (e.g. libs now can see docs TFM which is not useful).
My gut feeling is that Pros > Cons.
Similar to #4903.