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

Don't define NETCOREAPP3_1 when targeting .NET 5 #20692

Closed
terrajobst opened this issue Sep 17, 2020 · 2 comments · Fixed by #20848
Closed

Don't define NETCOREAPP3_1 when targeting .NET 5 #20692

terrajobst opened this issue Sep 17, 2020 · 2 comments · Fixed by #20848
Assignees
Labels
breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 5 Work items for the .NET 5 release

Comments

@terrajobst
Copy link
Contributor

terrajobst commented Sep 17, 2020

Don't define NETCOREAPP3_1 when targeting .NET 5

.NET 5 will now have the same behavior for defining preprocessor symbols as previous releases of .NET Core, that is, we only define symbols for what the project is actually targeting and no longer include defines for earlier versions.

Version introduced

.NET 5 RC2

Old behavior

Since .NET 5 Preview 7, targeting net5.0 defined both NETCOREAPP3_1 and NET5_0 preprocessor symbols. The intent was that starting with .NET 5, conditional compilation symbols would be accumulative.

New behavior

We'll revert this change which will make the behavior consistent with how preprocessor symbols were defined in previous releases of .NET Core (1.0 - 3.1).

Reason for change

Customer feedback. The new behavior was surprising and caused confusion on how to accommodate it. People assumed this was a bug in the C# compiler.

Recommended action

Ensure your #if logic doesn't assume that NETCOREAPP3_1 is defined when the project is targeting net5.0 or higher. Instead, assume that NETCOREAPP3_1 is only defined when the project targets netcoreapp3.1 exactly.

For example, if your project multitargets for .NET Core 2.1 and .NET Core 3.1 and you need to call APIs that were introduced in .NET Core 3.1, your #if logic should look as follows:

#if NETCOREAPP2_1 || NETCOREAPP3_0
    // Fallback behavior for old versions
#elif NETCOREAPP
    // Behavior for .NET Core 3.1 or later
#endif

Issue metadata

  • Issue type: breaking-change
@terrajobst terrajobst added 📚 Area - .NET Core Guide breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 5 Work items for the .NET 5 release labels Sep 17, 2020
@dotnet-bot dotnet-bot added the ⌚ Not Triaged Not triaged label Sep 17, 2020
@marcpopMSFT
Copy link
Member

@terrajobst it may be worth mentioning which preview this was introduced in. From code history, looks like we added this starting in preview 7. Is it worth mentioning NET for 5.0 and higher?

@terrajobst
Copy link
Contributor Author

terrajobst commented Sep 17, 2020

it may be worth mentioning which preview this was introduced in. From code history, looks like we added this starting in preview 7

Good call, I've added that

Is it worth mentioning NET for 5.0 and higher?

I'd rather not, because that behavior is unchanged and trying to describe that seems to cause more confusion...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
breaking-change Indicates a .NET Core breaking change 🏁 Release: .NET 5 Work items for the .NET 5 release
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants