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

Remove versioned defines #20179

Closed
4 of 5 tasks
danmoseley opened this issue Feb 10, 2017 · 10 comments
Closed
4 of 5 tasks

Remove versioned defines #20179

danmoseley opened this issue Feb 10, 2017 · 10 comments
Labels
area-Meta enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors
Milestone

Comments

@danmoseley
Copy link
Member

We should migrate to versionless platform defines. @joperezr @weshaggard can we do this now if not what has to come first? I see you already renamed all the C# file suffixes to be versionless.

  • #if netcoreapp11 --> #if netcoreapp
  • #if netstandard17, #if netstandard10 --> #if netstandard
  • #if netcore50 --> #if uap
  • #if netcore50aot --> #if uapaot

incidentally
#if NET46 -> don't change

  • # if NET_4_5 -> dead

Perhaps you already have something tracking this kind of thing.

@weshaggard
Copy link
Member

We can do that for all the test projects because we don't care about the versioned target frameworks for those projects. However we might still need to keep some of these for the ref/src projects if we care about that build configuration for that project.

@danmoseley
Copy link
Member Author

Can you clarify? I thought we now only build ref/src for the latest version. So we would never define eg netcoreapp11 would we?

@weshaggard
Copy link
Member

For ref/src that ship as an individual nuget package we may need to still have non-latest build configurations building so that the package can contain the correct assets. For anything that doesn't ship in an individual package you are correct they should always just target the latest (i.e. versionless) targets.

@danmoseley
Copy link
Member Author

Ah, so we go back to the issue of clearly distinguishing what is its own package. It's too bad we don't segreate the rest of corefx from those.

@danmoseley
Copy link
Member Author

I thought we doing harvesting for non latest configurations.

@weshaggard
Copy link
Member

Ah, so we go back to the issue of clearly distinguishing what is its own package. It's too bad we don't segreate the rest of corefx from those.

Unfortunately it is a clean cut in all cases. Consider Immutable collections it is ships in the platform package and in an individual package.

I thought we doing harvesting for non latest configurations.

We do in a lot of cases but in some cases, again like Immutable, we still want to produce live updated builds with new fixes for older targets.

@jkotas
Copy link
Member

jkotas commented Feb 11, 2017

I think #if netstandard should be deleted (and code under it kept). I do not think we need it.

@weshaggard
Copy link
Member

I think #if netstandard should be deleted (and code under it kept). I do not think we need it.

I agree in general the defines should be targeting a specific platform (i.e. netcoreapp, uap, netfx, etc) however there may be cases for libraries above netstandard to use that define in some cases if it is easier then negating the other specific platforms.

@jkotas
Copy link
Member

jkotas commented Feb 13, 2017

there may be cases for libraries above netstandard to use that define in some cases if it is easier then negating the other specific platforms.

Agree it makes sense to use it in these cases if they show up.

@msftgits msftgits transferred this issue from dotnet/corefx Jan 31, 2020
@msftgits msftgits added this to the Future milestone Jan 31, 2020
@jkotas
Copy link
Member

jkotas commented Jan 31, 2020

The defines are in sync with the SDK ones now.

@jkotas jkotas closed this as completed Jan 31, 2020
@ghost ghost locked as resolved and limited conversation to collaborators Dec 26, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
area-Meta enhancement Product code improvement that does NOT require public API changes/additions help wanted [up-for-grabs] Good issue for external contributors
Projects
None yet
Development

No branches or pull requests

4 participants