Compiler bug on field assignment

[Andrus]

If ExecuteQuery method sets fields, C# 3.5 compiler issues invalid warning
at compile time:

Field '... .Contents' is never assigned to

To reproduce, create class

class Entity<T>
{
public T Contents;
}

and compile lines

Northwind db = CreateDB();
var res = db.ExecuteQuery<Entity<int>>(@"select 1 as Contents from
Customers");


How to fix ?

Andrus.

 

[Marc Gravell]

Aside: Why set a field? Why not a property?

The warning is valid; from the compiler's perspective that field is
never set. You could perhaps just add a dummy private method to set it?

Marc

 

[Andrus]

The warning is valid; from the compiler's perspective that field is

never set.

Compiler does not produce warning if field is changed to property.

Why compiler considers that property is set but field is not set ?

Andrus.

 

[Jon Skeet [C# MVP]]

Compiler does not produce warning if field is changed to property.

Why compiler considers that property is set but  field is not set ?

It's not that it considers the property to be set - just that it
doesn't warn about unused properties.

If you really want to just get rid of the warning, you could use
#pragma warning disable

 before the field and then #pragma
warning restore [code] after the field.

Jon

 

[Ben Voigt [C++ MVP]]

If ExecuteQuery method sets fields, C# 3.5 compiler issues invalid
warning at compile time:

Field '... .Contents' is never assigned to

To reproduce, create class

class Entity<T>
{
public T Contents;
}

and compile lines

Northwind db = CreateDB();
var res = db.ExecuteQuery<Entity<int>>(@"select 1 as Contents from
Customers");


How to fix ?

Ignore the warning. You'd have the same problem with any other data
accessed only through reflection (say for example the only way to set a
field was through deserialization).