Summary of the problem
Back in 2018.4 a decision was made to remove the suppressor on the warning known as CS0649. This warning appears when a private or internal field is declared but never assigned a value.
When a MonoBehaviour contains a field that is private. One can add the attribute [SerializeField] to have the value shown in the inspector. This is because the inspector only shows serialized data and private fields are not serialized.
Since the removal of the suppressor, users have been seeing this message on their code:
âAssets\NewBehaviourScript.cs(8,12): warning CS0649: Field âNewBehaviourScript.myFieldâ is never assigned to, and will always have its default value nullâ
What we want from you
Please answer the following in a reply in this thread:
- Whatâs your level of unity experience?
- Whatâs the current project you are working on?
- Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
- Which solution should we focus on for new releases of Unity 2021.1 and above, based on the list after the solutions for 2018.4, 2019.4, and 2020.2?
Solutions for 2018.4, 2019.4, and 2020.2
Project Setting, reorderable list
In the project settings window we add a list of default suppressed warnings. This gives you the ability to keep or remove the list of suppressed warnings. In addition, this allows you to add new compiler arguments that you want to pass to the compiler. The arguments will be passed to every assembly being compiled in your project. In addition to suppressing the warning for SerializeField, the warning will also be suppressed for any other valid cases.
Project setting, checkbox
In the project settings window we add a toggle button to enable and disable a built-in list of these suppressed warnings. Compared to the list approach, you cannot add or remove any of the suppressors individually. As with the previous solution this will not only suppress the warning for SerializeField, the warning will also be suppressed for any other valid cases of this warning.
Suppress the Warning by Default
In this case we would suppress the warning by default. There will be no UI to either enable or disable the behaviour. This was the old solution before the regression was introduced. This will work exactly as in 2017.4.
Nothing
None of the solutions will be applied. You can use one of the following workarounds to resolve the problem.
Today you can remove the error by adding the following pragma statements in your code:
#pragma warning disable 0649
[SerializeField]
private string m_MyField;
#pragma warning restore 0649
This will suppress the individual warning the pragma block is covering.
Another possibility today is to add a csc.rsp file the file content:
-nowarn:0649
By changing the field to public and not using SerializeField the warning will not be shown.
Assigning a default value to the field will do the same.
Solutions going forward
In order to make a more focused solution to this problem, we want to hear which solution we should be implementing going forward.
Assembly Definition Inspector
In the inspector of an .asmdef file we add a field where you can type in the additional compiler arguments you want to pass along. These arguments can be any of the ones supported by the Roslyn Compiler.
By suppressing the warning in this fashion this will not only suppress the warning for SerializeField, the warning will also be suppressed for any other valid cases of this warning.
This method will only work if your code is structured in this manner. If you do not have an asmdef for the project, it will not be possible to add these additional arguments.
This will function similar to the Project Setting approach. The main difference will be that this setting is per assembly. This will allow the assembly to add additional compiler arguments in addition to the ones that are hardcoded.
Roslyn Analyzer
With the newly added support for Roslyn Analyzers in 2020.2, we can add an analyzer to specifically suppress the warning for SerializeField. This will not add the ability to add additional compiler arguments.
We would ship these analyzers as a package that can be added to the project. They would work the same way as Visual Studio and JetBrains today is suppressing this warning in their code editors. These analyzers can be found here: GitHub - microsoft/Microsoft.Unity.Analyzers: Roslyn analyzers for Unity game developers and can be used in 2020.2 in the newest release of the code editor.
In addition, we can append a better message to the compiler warning to notify users about this possibility of adding the package to suppress the warning for SerializeField.
Changing Best Practices
We update our documentation to explain that a field should be public if you want it visible in the inspector. Rewrite the SerializeField documentation with a note that this pattern is not recommended and the issue that one can run into.
In addition we can append a better message to the compiler warning to notify users that this pattern is not recommended and to make the field public or assign a value to it in the code.
Nothing
