Core: .NET Core 2.1 - Breaking Change

Created on 31 May 2018  路  8Comments  路  Source: dotnet/core

.NET Core 2.1 - Breaking Change

After upgrading one of my projects from .NET Core 2.0 to .NET Core 2.1, it would no longer compile. The issue seems to be related to the CancellationTokenRegistration type or perhaps some change/bug fix related to uninitialized local variables.

General

I am running Visual Studio 2017 Community v15.5.2 on Windows 10. The error code reported to me by VS was: "(Code: CS0165) Use of unassigned local variable 'tokenRegistration'"

Here is the code which triggered the error:

```c#
Task task = new Task(() =>
{
CancellationTokenRegistration tokenRegistration;

try
{
    // Boring task logic.
    ... 
}
finally
{
    if (tokenRegistration != default(CancellationTokenRegistration)) // Error here!
    {
        tokenRegistration.Dispose();
    }
}

},
cancellationToken.Value,
TaskCreationOptions.LongRunning);
```
The fix was to change to initialize the 'tokenRegistration' variable to 'default(CancellationTokenRegistration)'. Looking at the code now, I'm wondering how it ever compiled.

Most helpful comment

I believe this is caused by https://github.com/dotnet/corefx/issues/6185.

In short, previously, reference assemblies didn't contain private fields for structs such as CancellationTokenRegistration. This meant that C# didn't check definite assignment for those types, which allowed code like your example. This bug was fixed in .Net Core 2.1, which means that code that compiled and worked fine before, but was in some sense incorrect, because it didn't initialize types that should be initialized, does not compile anymore.

All 8 comments

Update your vs to version 15.7 at least

I believe this is caused by https://github.com/dotnet/corefx/issues/6185.

In short, previously, reference assemblies didn't contain private fields for structs such as CancellationTokenRegistration. This meant that C# didn't check definite assignment for those types, which allowed code like your example. This bug was fixed in .Net Core 2.1, which means that code that compiled and worked fine before, but was in some sense incorrect, because it didn't initialize types that should be initialized, does not compile anymore.

@VladislavAntonyuk I will try upgrading to the latest version of VS 2017 and get back to you.

@svick Very interesting, thanks for the info! That seems to line up with what I suspected.

screen shot 2018-06-06 at 3 21 59 pm
interesting thing was that different struct had a different behavior before i got a breaking change too on this but really easy to fix just add a default value

Same breaking change is happening in UWP apps after updating to Microsoft.NETCore.UniversalWindowsPlatform NuGet 6.2.0+
48697530-1eb4be80-ebe5-11e8-8e3a-d1bca379fc4d

@martinsuchan that should be separate bug. Is it a compiler error or "just a warning"?
@HollyAM @MattWhilden where do you track UWP bugs?

It's a change of struct signature. Added private fields now prohibit usage of just Size size; for initialization.
It's discussed in more detail here: https://github.com/Microsoft/dotnet/issues/927

Ah ok, so that one is primary and we do not need another UWP tracking bug, is that correct?

Was this page helpful?
0 / 5 - 0 ratings

Related issues

steevcoco picture steevcoco  路  4Comments

ugurcemozturk picture ugurcemozturk  路  3Comments

mmacneil picture mmacneil  路  3Comments

lesomnus picture lesomnus  路  3Comments

omerlh picture omerlh  路  4Comments