Search Issue Tracker


Planned for 2019.4, 2020.1



Found in



Issue ID




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



1. Open the attached project (
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


    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.


    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.

Comments (78)

  1. 022c156d76ef8c3212a324c252fa9fbe?d=mm


    Dec 19, 2018 17:41

  2. 022c156d76ef8c3212a324c252fa9fbe?d=mm


    Dec 19, 2018 17:19

    I wonder if fixing this would require a modification to the Rosyln compiler to allow Attributes to flag a field as used? This IS actually possible because Rosyln is open source, and Unity has a seat at the .NET Foundation table.

    Alternately, they could inject the pragma statements at build time for all [SerializeField] entries.

    Regardless, "By Design" is kind of a lie. More like "ignoring this regression because fixing it is hard."

  3. 4add713e779775fe058fe48e42bb5abc?d=mm


    Dec 17, 2018 21:51

    This should be fixed, using [SerializeField] is the preferred method so it should be made easy, having everything public is bad practice.

  4. 268e488556c0e9e604ef13d23f63ce62?d=mm


    Dec 15, 2018 16:31

    Ahh no! I didn't read that someone already said what I said with the #pragma warning disable option.. sorry in advance! Lol :(

  5. 268e488556c0e9e604ef13d23f63ce62?d=mm


    Dec 15, 2018 16:30

    You can put a preprocessor directive at the beginning of your script to take the warnings away:

    #pragma warning disable 0649

    I too, love using [SerializeField] private in my scripts to keep encapsulation but also make use of the inspector, so I put this preprocessor directive in each script when I need it. 0649 comes from the warning code, written in the warning messages in the console. For example, it'll say something similar to this:

    "Assets\Scripts\YourScript.cs(22, 38): warning CS0649: Field '...' is never assigned to, and will always..."

    The CS0649 part gives you the warning number, and you can ignore other warnings with this too! ;)

  6. 365be149d78af8e38ce076783fef5698?d=mm


    Dec 12, 2018 14:28

    This can't possibly correct behaviour. Like many have mentioned [SerializeField] is used to specify that the editor WILL (and always will) assign a value to the variable, so it IS assigned to, and doesn't have its default value (unless Unity assigns the default value to it). This _has_ to be fixed. The only working alternatives would be to completely disable ALL WARNINGS about unassigned variables, and that would be quite bad, or having to add a [UsedImplicitly] to all [SerializeField] variables, which seems completely pointless, since it's already implied by the [SerializeField] that it WILL be used implicitly.

  7. 51fe144949b3926795b04c14e7466e3c?d=mm


    Dec 01, 2018 23:33

    I agree with Flavelius.

    Using the [SerializeField] attribute should prevent the all these warnings, otherwise, it makes no sense to use the attribute at all.

    I thought the whole point of [SerializeField] was so that we could have fields visible in the inspector while keeping them private.

    Is this truly considered "by design"?

  8. B797449429747ef4341b4939a00b2ce8?d=mm


    Nov 21, 2018 06:41

    The compiler is wrong in reporting the additional warnings. [SerializeField] is most prominently used exactly to assign values in the inspector. Unity also is all about magic functions and magic switches, so this should and can most likely be adjusted (the previous compiler had this magic adjustment, showing that it must be possible).

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.