I recently started a new job. They are using C# 5 back here, a pretty old language version, for multiple projects targeting .NET Framework 4.5.2. Multithreading is involved heavily here. I could not find any information about the impact of raising the language version of a *.csproj, so the title says it all. What changes are involved by raising the language version to, let's say, 7.3?
Asked
Active
Viewed 739 times
7
-
3Yes, there are considerable risks. A standard one is that not everybody in the team is using the latest VS version, so your check-in will produce a compile error for them. That is *not* a good way to introduce yourself, be sure to talk to the team members about that. Ask about coding conventions while you're at it, every team agreed about what not to do. SO is not the right place for that kind of advice, don't be shy. – Hans Passant Jan 03 '19 at 14:20
-
1I won't do this without having an agreement with my colleagues, but thanks for the advice! – PeteSabacker Jan 04 '19 at 06:58
2 Answers
1
The C# language is backwards compatible. You don't have to worry about that.
The CLR on the other hand does sometimes introduce changes (sometimes bugs) under the hood. And you might need to switch to a newer version when language features aren't supported on older Framework versions. This might affect your program in an unforeseen way. Testing is your friend here.
Patrick Hofman
- 153,850
- 22
- 249
- 325
-
Is the CLR version equal to the Framework version? I've just set the language level to 7.3, everything *seems* to be fine, no issues occured so far. However, automated tests are impossible - since nobody cared about that in the past here. I'm especially worried about changes applied by the compiler. – PeteSabacker Jan 03 '19 at 13:16
-
2No, it is not. Usually you shouldn't expect to many problems, but you can never be sure until you test it properly. Now you have a good case to introduce unit tests. – Patrick Hofman Jan 03 '19 at 13:17
-
Ha, would you do me a favour to tell that to the product owner? I know you are right, but automated tests are not considered "cost-efficient" around here. – PeteSabacker Jan 03 '19 at 13:20
-
-
-
"does sometimes introduce changes (sometimes bugs)": very vague statement. Ever really experienced this? In my experience changing the Language version for a project > 100 projects did not introduce a single bug. A language version itself could have bugs if just released but as of now c# 7.3 should be stable.. – Daniel Bişar Sep 15 '21 at 10:40
-1
I don't see risks. C# doesn't have breaking changes in 7.3, compared to 5. 8.0 is to introduce non-nullable types, which will cause a storm of warnings throughout the code, but no so in 7.3.
Nick
- 4,787
- 2
- 18
- 24
-
-
-
-
"8.0 is to introduce non-nullable types, which will cause a storm of warnings throughout the code" as FCin noted this is also not true. – Patrick Hofman Jan 03 '19 at 13:13
-
3@PatrickHofman - technically, the change to `foreach`/variable capture in C#5 was a breaking change though anyone who'd deliberately built code based on the older semantics deserved breakage. – Damien_The_Unbeliever Jan 03 '19 at 13:19
-
-
2@PatrickHofman - "What's new in C# 5" doesn't seem to exist on the MS site these days but here's a [Eric Lippert answer](https://stackoverflow.com/questions/8649337/is-access-to-modified-closure-resolved-by-comprehension-syntax/8649429#8649429) from around that timeframe (and it did make it into C# 5) – Damien_The_Unbeliever Jan 03 '19 at 13:22
-
@Damien_The_Unbeliever That is a good one, but indeed more a fix that a real change. – Patrick Hofman Jan 03 '19 at 13:24