Search Issue Tracker

Fixed in 2021.1

Fixed in 2018.4, 2019.4, 2020.1, 2020.2

Votes

216

Found in

2018.3.0a1

2018.3.0b1

Issue ID

1080427

Regression

Yes

[SerializedField] fields produce "Field is never assigned to..." warning

Scripting

-

1. Open the attached project (warning.zip)
2. Observe the warning in the console

Expected: field with SerializeField attribute do not produce the warning

Reproduced in 2018.3.0a1, 2018.3.0b1, 2018.3.0b2, 2019.1.0a1
Did not reproduce in 2018.2.8f1
Regression introduced in 2018.3.0a1

  1. Response avatar

    lukaszunity

    Nov 06, 2019

    #pragma warning disable 0649
    // your code
    #pragma warning restore 0649

    Or disable it globally by adding a file named csc.rsp to the root of you Assets folder, e.g. Assets/csc.rsp, with the following contents without quotes.

    /nowarn:0649

    This will tell the C# compiler to not emit a warning for CS0649 / unused fields.

    If you have .asmdefs with csc.rsp in your project, then you also need to add the "/nowarn:0649" line to those csc.rsp files.

  1. Response avatar

    Resolution Note (fix version 2021.1):

    A list where you can pass additional compiler arguments as well as a toggle to suppress common warnings is added in the Player Settings
    Fixed in 2021.1.0a2

  2. Response avatar

    Resolution Note (fix version 2020.2):

    Fixed in 2020.2.0b9

  3. Response avatar

    Resolution Note (fix version 2020.1):

    Fixed in 2020.1.11f1

  4. Response avatar

    Resolution Note (fix version 2019.4):

    Fixed in 2019.4.15f1

  5. Response avatar

    Resolution Note (fix version 2018.4):

    Fixed in 2018.4.29f1

Comments (82)

  1. 0a40fa27a039a2b7dd9ce39fcc2a22e4?d=mm

    jduffy_unity

    Jun 26, 2020 01:39

    Best workaround I've found is to make non public fields protected. It gets rid of the warning and has the added benefit of making it impossible to name mangle serialized fields across subclasses.

  2. B0a582ab5ab2b5826d5b837a053a7fab?d=mm

    BoteRock

    Jun 09, 2020 16:22

    People having this issue:
    You can also set the field as public, this way also aligns more with the view of "Component Oriented Programming" as components are not designed to be operated alone, and are not expected to be "self contained"

    There is nothing wrong in using public, and it will help you find other patterns that are neater.

    Purists may think this is wrong. But just think in the project and the best way to make your life easier working on it. You don't have to live to c# compiler developers expectations, you just need to make your game, and make it run good and fast. It is much simpler if you don't have to wonder "should this thing be serializefield private, or public instead".

    I invite you to leave that dogmatic OOP "things shouldn't be public because they're not meant to be edited from outside". Most of the time, you are waisting brain time thinking on that. And when it really matters you will have clear motivations about why you need to do one think or another.

    In the meantime, don't bother and use public.

  3. 7235883c0e17d85ad807508682564c94?d=mm

    Laurent_Giroud_Nvizzio

    May 27, 2020 19:39

    People who are (rightfully) shocked that this is not fixed => PLEASE VOTE FOR THIS BUG.

    Commenting here is not going to help but voting will.
    (If every commenter had voted, it would be long fixed.)

  4. C3310c2c30b196c8619df64fea5d7a6e?d=mm

    ClausKleber

    May 25, 2020 09:42

    You could simply assign null to the serialized field instead of using a hacky workaround like #pragma warning disable 0649.

    E.g.:
    [SerializedField]
    private GameObject test = null;

  5. 63eb28e1176e9f6c641763274bf6d48e?d=mm

    Ziflin

    May 16, 2020 20:02

    Argh!! It appears csc.rsp and mcs.rsp files are no longer being read in 2020.1.0b8? Is this another bug with recent changes to Visual Studio Projects?

    * Other VS integration bugs include it randomly deciding to detach from VS such that the default .cs file viewer is used instead of VS when opening scripts from Unity.
    * The VS debugger refuses to start until VS is restarted.
    * And the super annoying "Your project has changed, do you wish to reload?" is back.

    I had none of these problems in 2019.3 until upgrading to 2020.1. Now I end up restarting VS about 30 times a day.

  6. 3b7fd7be0a8cfd84d035964c7d262b20?d=mm

    IARI

    Apr 30, 2020 11:18

    six years, seriousely?
    This really needs to be fixxed.

  7. 35b96a6ddb225ade604d05df2a2db598?d=mm

    Kaymax

    Apr 24, 2020 02:32

    reported just right before found out we have open issue, anyway let it be 2

  8. 9ef2dff0164fbaf6448b38060bcd106c?d=mm

    dorbelian

    Apr 23, 2020 13:08

    I understand that it seems to you that you better know what we need, but we really need it, so be so kind as to fix it as soon as possible.

  9. 5bb847a3478809203abcbd37ebb658b6?d=mm

    Inboxninja

    Apr 22, 2020 02:24

    oops! wrong ticket

  10. 5bb847a3478809203abcbd37ebb658b6?d=mm

    Inboxninja

    Apr 22, 2020 02:20

    this has been "postponed" for 6 years. Can we get a fix please?

Add comment

Log in to post comment

All about bugs

View bugs we have successfully reproduced, and vote for the bugs you want to see fixed most urgently.