Suggesting solutions for SerializeField warning

[Kamyker]

For Linux and Mac?

Not sure, there’s also mac version you can try to build from GitHub - microsoft/Microsoft.Unity.Analyzers: Roslyn analyzers for Unity game developers

[xVergilx]

• What’s your level of unity experience?
  – Hobbyist since 2015, dayjob worker / developer since 2017.

• What’s the current project you are working on?
  – Multiple mobile projects (Unity v2019.1, 2019.2, 2019.3, 2019.4) on the work and a hobby project at home (Unity 2019.4)

• Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
  – Roslyn Analyzer fix or ignore it by default.

• 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?
  – Roslyn Analyzer fix or ignore it by default.

Making each field public is extremely bad practice, please stop promoting it in the manual.

Currently I’m using default initializers for those fields. It was extremely annoying at first to update large codebases for the projects to the “= default style”. Now - I don’t really care that much. Its basically a muscle memory.

[miniwolf_unity]

I want to thank everyone here in the thread for adding their voice to this situation. It is one of the most up-voted issues we have seen in my team for a while. It was opened quite a while back. It was closed. Re-opened by public demand. We took good care to ensure that we fix this issue in the right way this time. We do not want another downfall down the line.

Here is the solution that we are going with. I try to sum up how it solves the problem and what it means for different scenarios.

For 2018 LTS, 2019 LTS, and 2020 LTS we will be adding the reorderable list inside the project settings window. This will be landed as fast as possible, as you have waited enough for a solution to this problem.
How does this solve the problem users are facing currently?
By default add the suppressor to the list. This gives new users, beginners, those who just want things to work, a clean experience. We are not showing them a warning that is not actionable and leads to confusion.
For the advanced user, who understands the implication, you can remove the suppressed warning. The list is completely modifiable. You can add and remove any compiler arguments you want to pass project wide (to all assemblies).

---

Going forward we will be adding Roslyn suppressors in package that will be shipped default with projects. These can be toggled off as any other package in Unity. It is not known as of yet when this project will be prioritised.

[system]

@miniwolf_unity

Going forward we will be adding Roslyn suppressors in package that will be shipped default with projects. These can be toggled off as any other package in Unity. It is not known as of yet when this project will be prioritised.

Hi,
Forgive me for the dumb question but where will the “Roslyn suppressor in packages” be? I hope they won’t be added to the Visual Studio and Rider editor support packages because I’m not using them.

[Baste]

Sounds like it’s own package in the package manager.

[Kamyker]

[quote=“Kamyker, post:19, topic: 806898, username:Kamyker”]
Dig for bit and there’s a fix that probably works for 2018.4+ (works for me in 2020.1)
[/quote]Oh it seems like it’s working for me as I’ve updated C# compiler manually. It is already updated in Unity 2020.2 so it will work out of box from that version.

[angrypenguin]

• What’s your level of unity experience?
  Professional, working with it for a wide variety of projects since v1.6.

• What’s the current project you are working on?
  Open world exploration game right now, but I’ve done all sorts.

@miniwolf_unity

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.

Heck no, not this one. I’d be up for a review of how stuff gets exposed to the Inspector*, but officially recommending against the use of [SerializeField] in favour of something that gives you less control would be a step backwards from my perspective.

Just because something is available in the Inspector does not mean I want other scripts to be able to change it. And wanting scripts to access stuff does not mean I want to expose it to designers. So, please, don’t advocate for combining those things!

• Particularly when it comes to properties, which are not exposed by the default Inspector at all.

@miniwolf_unity

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.

I like this one. However, since you’re making a UI anyway, it’d be neat to go one step further and also add a list of common stuff that we can tick / untick and have it add them into the argument list for us.

@miniwolf_unity

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.

I like this one, with the same addition as above - a UI element to add/remove common ones.

In the future, when you get to the ASMDEF one, there should be a button in the UI which brings up the global list in the project settings, too.

Question… why does it matter that it’s a “reorderable” list?

Edit: As a follow up, I’m really glad to see so many people here strongly advising against the proposed change to best practices.

[rarepop99]

@angrypenguin

Question… why does it matter that it’s a “reorderable” list?

I don’t think the “Reorderable” part will make a difference per se. It would just be a list basically

[steinbitglis_1]

@rarepop99

I don’t think the “Reorderable” part will make a difference per se. It would just be a list basically

Hmm. All lists are reorderable per se… it’s just that Unity thinks that reordering some of them should be difficult, I think.

[rarepop99]

@steinbitglis_1

Hmm. All lists are reorderable per se… it’s just that Unity thinks that reordering some of them should be difficult, I think.

It’s more that historically some of those lists were not reorderable, which could be annoying to work with in some cases.

[Kamyker]

Ehh… That list “solution” is as good as adding csc.rsp to default project template.

Hopefully there will be API to add something to the list then making package with Microsoft.Unity.Analyzers and a:Packages\com.bestname\Microsoft.Unity.Analyzers.dll will take 10 mins.

[CaseyHofland]

1. 3 years now, 1 year DIY and 2 years education primarily using Unity.
2. Can’t say (confidentiality and all that).

@Detour_Guide

The re-orderable list would be useful in general, but CS0649 should be suppressed by default.

I completely agree, I’m using a csc file right now in every project and it always has at least 0649 in it. The interface would have been nice when I was just a wee lad stumbling with this issue (who am I kidding, I’m still a wee lad). However, the more hardcore programmers among us should be able to remove the nowarn and this seems the best option.
4. I’ve got no opinion on this, I haven’t dabbled in dll’s too much (I mean I have, but not like that).

Fire the guy that suggested the documentation change, how dare he.

[lucasvarney96]

• I have been working with Unity for about 3 years, but I have been programming for much longer (about 9 years total.)
• A top down shooter with a built-in level editor.
• Reorderable list, but Roslyn analyzers would be preferable if possible
• Roslyn analyzer

@miniwolf_unity

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.

I think we should avoid this at all costs. Public fields aren’t a good or safe practice, and can be especially dangerous to new programmers. The recommended practice should be to [SerializeField] a private field, and then expose it in a property if necessary.

[Dmitry-Pyalov]

1. CS background. 13 years of C#. 7 Unity projects launched on almost all available platforms.
2. 2D game not yet announced
3. Nothing. Visual Studio showed those warnings since the beginning. #pragma works fine
4. Roslyn or nothing. We never researched Roslyn, but all other options sound bad.

[emerge-sjh]

• What’s your level of unity experience?
  15+ years
• What’s the current project you are working on?
  Some stuff I can’t talk about lol
• Which solution should we implement for 2018.4 LTS, 2019.4 LTS and 2020.2 based on the list below?
  Setting a default value, like the warning suggests (and is good practice in general, imho.
• 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?
  Roslyn analyzer? sure. But imho I think people are complaining about a completely valid warning and they’re just too lazy to initialize the variables.

[vharutyunyan]

1. Unity experience - 4 years
2. Working on several 2D mobile games as a contractor
3. Suppress common warnings checkbox. I think everyone was fine before the change that caused those warnings to appear.
4. Roslyn analyser.

[McDev02]

First I always make my Inspector fields private as this is simply a quick way to define data that I would otherwise store in other serialized ways, such as scriptable objects or JSON files. But for small projects this is just a ridiculous overhead. They will only become public if they have to be accessed by another class.

• Hobbyist for 10 years, professional for 5 years
• Too many… Rather small Web, VR and AR apps for marketing purposes
• I can not think of additional warnings that I want to suppress currently, so the Suppress common warnings checkbox checked by default should be fine. If there is still the option to simply add a csc.rsp file, I think that serves everyone and does not clutter the Player settings even more.
• Abstention

[Ziflin]

I agree with @McDev02 that suggesting that fields have to be public to be editable is silly. Proper class design should not be dictated by this issue.

1. Professional Game Engine Developer for ~20 years.
2. Unity Diablo-ish like RPG.
   3 & 4. Asmdef makes the most sense to me. This should be a per-library (assembly) setting and not dictated by a global setting.

Ideally this would be solved by an attribute that C# compilers recognize to treat the variable as reflection-initialized. Then the [SerializeField] attribute could derive from it and we could stop having this insanely long discussion over something all C# compilers should support. For instance, how does the [DataMember] attribute work on private fields without a similar issue?

[imangitarrowood]

1. 5 years Unity, 15 years game dev, tech director at a mid-sized studio
2. Unannounced mobile game
3. Agree with Ziflin, needs to be per assembly
4. Roslyn Analyzers solution would be better in the long term, targeting the specific case of the issue instead of suppressing a useful warning globally or even per assembly

And I’ll add my voice to the chorus of absolutely do not make public fields a best practice.

[rarepop99]

Hi, a little update on this.

We have landed fixes all the way back to 2018.4!

For 2018.4 and 2019.4 we have restored the previous behaviour where we ignore CS0649, without a way to change it.
However, from 2020.1 you have a checkbox to ignore (or not) the previously hardcoded CS0649 and CS0169 in the PlayerSettings.
From 2020.2 you have both the checkbox mentioned above AND a re-orderable list in which you can choose to add any compiler arguments from Compiler Options - C# reference | Microsoft Learn