Mixing
Any risks involved in raising the langauge version number of a C# project?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty{ height:90px;width:728px;box-sizing:border-box;
}
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?
c#
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
add a comment |
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?
c#
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
2
Yes, 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 3 at 14:20
1
I won't do this without having an agreement with my colleagues, but thanks for the advice!
– PeteSabacker
Jan 4 at 6:58
add a comment |
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?
c#
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
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?
c#
c#
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
asked Jan 3 at 13:03
PeteSabackerPeteSabacker
516
516
2
Yes, 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 3 at 14:20
1
I won't do this without having an agreement with my colleagues, but thanks for the advice!
– PeteSabacker
Jan 4 at 6:58
add a comment |
2
Yes, 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 3 at 14:20
1
I won't do this without having an agreement with my colleagues, but thanks for the advice!
– PeteSabacker
Jan 4 at 6:58
2
2
Yes, 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 3 at 14:20
Yes, 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 3 at 14:20
1
1
I won't do this without having an agreement with my colleagues, but thanks for the advice!
– PeteSabacker
Jan 4 at 6:58
I won't do this without having an agreement with my colleagues, but thanks for the advice!
– PeteSabacker
Jan 4 at 6:58
add a comment |
2 Answers
2
active
oldest
votes
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.
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
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 3 at 13:16
1
No, 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 3 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 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
add a comment |
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.
answered Jan 3 at 13:06
NickNick
2,3671215
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
3
@PatrickHofman - technically, the change toforeach/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 3 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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
|
show 3 more comments
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54022875%2fany-risks-involved-in-raising-the-langauge-version-number-of-a-c-sharp-project%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
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.
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
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 3 at 13:16
1
No, 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 3 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 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
add a comment |
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.
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
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 3 at 13:16
1
No, 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 3 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 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
add a comment |
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.
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
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.
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
answered Jan 3 at 13:09
Patrick HofmanPatrick Hofman
129k18180239
129k18180239
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 3 at 13:16
1
No, 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 3 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 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
add a comment |
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 3 at 13:16
1
No, 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 3 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 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
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 3 at 13:16
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 3 at 13:16
1
1
No, 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 3 at 13:17
No, 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 3 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 3 at 13:20
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 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Fixing bugs in production are I guess? @PeteSabacker
– Patrick Hofman
Jan 3 at 13:20
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
Yep, you got it.
– PeteSabacker
Jan 3 at 13:21
add a comment |
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.
answered Jan 3 at 13:06
NickNick
2,3671215
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
3
@PatrickHofman - technically, the change toforeach/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 3 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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
|
show 3 more comments
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.
answered Jan 3 at 13:06
NickNick
2,3671215
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
3
@PatrickHofman - technically, the change toforeach/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 3 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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
|
show 3 more comments
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.
answered Jan 3 at 13:06
NickNick
2,3671215
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.
answered Jan 3 at 13:06
NickNick
2,3671215
answered Jan 3 at 13:06
NickNick
2,3671215
answered Jan 3 at 13:06
NickNick
2,3671215
answered Jan 3 at 13:06
NickNick
2,3671215
2,3671215
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
3
@PatrickHofman - technically, the change toforeach/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 3 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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
|
show 3 more comments
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
3
@PatrickHofman - technically, the change toforeach/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 3 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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
Isn't the 8.0 nullable types feature optional?
– FCin
Jan 3 at 13:08
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
@FCin Yes, it is an opt in.
– Patrick Hofman
Jan 3 at 13:10
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
"C# doesn't have breaking changes in 7.3" it never had.
– Patrick Hofman
Jan 3 at 13:12
3
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 3 at 13:19
@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 3 at 13:19
2
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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
@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 from around that timeframe (and it did make it into C# 5)
– Damien_The_Unbeliever
Jan 3 at 13:22
|
show 3 more comments
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f54022875%2fany-risks-involved-in-raising-the-langauge-version-number-of-a-c-sharp-project%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
2
Yes, 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 3 at 14:20
1
I won't do this without having an agreement with my colleagues, but thanks for the advice!
– PeteSabacker
Jan 4 at 6:58