When scripting version is set to 4.x the warning CS0649 is not suppressed for private / protected fields marked with [SerializeField]
Is the behavior different with the .NET 3.5 Equivalent scripting runtime?
Yes, theyâre completely ignored.
Thanks! It looks like we have a bug report on this issue now, so we will investigate it.
https://issuetracker.unity3d.com/product/unity/issues/guid/1080427/
As far as I remember, this matches the behavior as if you compile in Visual Studio. I find it useful that Unity spits out the CS0649 warning, as it matches VS. I prefer to write and compile in VS and having Unity and VS match warnings is beneficial to me.
Thank you for looking into the issue, but I donât really agree with it being marked as By Design. I mean, yes; without the attribute, it absolutely should output the warning, but with it, the field can be edited through Inspector, so it no longer makes sense.
Using the attribute in a way which was intended makes it work as intended â but now also produces a warning which cannot be removed â because itâs not a mistake.
In another thread, I posted a few ways I thought of to suppress the warning, but none of it sounds entirely ideal.
It was a bit annoying seeing the squiggly lines in Visual Studio, but in the current beta, having 70 âwarningsâ outputted in the Console each time Unity compiles is on entirely different level.
Matching compile warnings are certainly beneficial, I agree, but if it turns one of Unityâs features into a warning By Design, I think Iâd rather avoid seeing it.
@Racoon_7 It can be avoided by assigning default values to the properties.
But going through a ton of code simply to get rid of the 100+ warnings will be real pain.
Not sure why the heck it should be âBy Designâ. Obviosly Unityâs design is different. Weâre not writing C# bussintheass applications here, please stick to your own enforced previously conventions.
Gonna second everyone else here, having this be âby designâ is insane. Youâre essentially saying that using the attribute in the intended way, as you show in the docs, should spam warnings.
What?
This really drags out a big, big annoyance with the issue tracker. Whenever something annoying is âby designâ, itâs generally really aggravating for users that are affected by the issue. But thereâs almost never an explanation for why itâs by design. Generally, you have pretty good reasons for not fixing an issue, which if spelled out would satisfy most people running into the issue - or at least give enough reasoning for them to let it lie. But when that isnât written down, you end up with frustration (and forum rage) instead.
Whenever something is marked as either by design, or as âwonât fixâ, there should really be a mandatory field where an explanation for why this isnât a bug that will be fixed is written down. If you add a special field to the issue tracker to explain why something has the label it has (unless itâs âwill be fixedâ), it would be much easier for us to understand your intentions, and generally breed more confidence in the community that youâre taking our issues seriously.
Now Iâm guessing that this time itâs just a miscommunication - since you replied to the thread - but I just have to assume. If you take the âby designâ at face value (which you would do if you didnât happen to read this thread), it seems directly incompetent.
Hello,
I responded in bug with reasoning of why issue was closed and workarounds. It didnât make it to public issue tracker.
The new C# compiler (Roslyn) is correct in reporting the additional warnings. This is same as you would get in any C# project/code in VS. The mono C# compiler did not report them in past.
You can disable the warnings with pragmas:
#pragma warning disable 0649
// your code
#pragma warning restore 0649
Or disable it globally by adding a csc.rsp file to your project and adding command line switch to disable the warning: -nowarn:0649
Thanks,
Jonathan
But that would disable the actual useful warnings as well. Going through all source code and marking them as excluded is no solution. I might simply initialize them to default values instead, if thatâs the case.
I wonder. Is there any code that performs filtering in native console (Editor native side)?
It would be much more useful to check if those fields are actually marked as [SerializeFields], then simply donât output the message if itâs true.
Default console is now a broken toaster with all the warnings that will crop out.
(Send Messages in OnValidate when checking if object is a prefab, this one, multiscene setup warnings. ugh)
You really should, every time. This is what I meant earlier - when you donât make replies to bugs public, you cause massive frustration in the community. For the specific person reporting the bug, they get a reason for why the bug was closed without a fix, but for the rest of the community, itâs just a big middle finger saying âdeal with itâ.
As a different example, hereâs a bug I reported. I had a pretty pleasant back-and-forth with the QA team, and I got a satisfactory reason for why it wonât be supported. Iâm happy. For the rest of the community, that page says âUndo is broken by designâ.
This is a failure of communication, and itâs so easy for you to fix it! You have written the reason down somewhere, you literally just have to copy-paste it.
Also jeez louize this is not the correct thing to do. The compiler is wrong, since it doesnât understand the semantics of the [SerializeField] attribute. The correct thing to do here is to go in and suppress this warning before it hits the console. Rider/Resharper does just that with the Unity plugin, I assume VSâ/VS Codeâs Unity plugin does that same? They should.
If developers follow the standard community guidelines, every single serializable field that doesnât have a good reason to be public is marked as [SerializeField] private. Weâll be spammed with thousands and thousands of warnings for doing the correct thing. Your workarounds have major downsides - either turn the warning off (which is a bad idea, itâs a useful warning), or add thousands of #pragmas to projects that clutter everything up.
As @VergilUa is alluding to, the 2018 cycle is spamming down the console with crap we canât do anything about to the point where itâs becoming near useless. Itâs an important tool for us, and youâre essentially degrading it with every update to the engine.
I have added the informative text and the public issue tracker info will be updated with it shortly.
No argument here. This is a problem and we need to solve it. Thanks for the clear words, weâre looking into this.
So, it wonât be fixed, am I right?
Should I start refactoring all my code base then?
Hm. Thank you for the information. âItâs not possible to fix thisâ sounds better than âwe want it to be like thisâ.
What about Visual Studio Tools for Unity? Could it be fixed from their side? Or is it just âwhatever the compiler spits out ends up in the consoleâ?
@VergilUa â Thanks for the tip about initialising the fields with their default value. The IDE still complains (âRedundant initialization with a default valueâ), but thankfully the warning in Unity is gone.
Because this issue involved a bunch of packages from the Asset Store which I didnât want to spend much time refactoring, I ended up âfixingâ this âerrorâ with a regular expression.
Since C# 7.1 you can do something like:
[SerializeField] float runSpeed = default; // â 0f
[SerializeField] Texture2D texture = default; // â null
So I think I replaced every field without an âequalâ sign on the same line (= unassigned)
\[SerializeField\]([^=]+?);
with
[SerializeField]\1 = default;
It helped me get rid of a few dozen warnings at once.
Itâs not related to the tools, but rather an actual Unityâs native console.
I was able to ignore multiple warnings selectively, but, with a different, custom written console.
So itâs possible, just UT seems to be on the lazy side. Or, because console is C++, it might be hard for them to pull the attributes for the actual field. Who knows, without the source - itâs impossible to tell the reason.
As a result, I ended up disabling default console and using custom one instead. Though, Application.logMessageReceived isnât as reliable as well. Sometimes it looses some messages sent in Editor.
Although, this is not a scalable solution, as people wonât be using same console setup. So itâs no go for distributable packages.
This warning message is definately should be ignored by default when console receives it.
I hadnât thought of that. To be honest, that makes this a lot less severe than I first thought.
Alas you cannot inialize fields this way on structs :
Assets/Scripts/...: error CS0573: '...': cannot have instance property or field initializers in structs```
So the problem remains : either lots of warnings are lots of pragmas for something done the expected way.
Hi all, Hi @joncham ,
is there really no way this can be revisited? I personally think the workarounds are not acceptable. This will lead to projects being cluttered by compiler warnings and serious issues will be overlooked. Initializing everything explicitly by the default value just moves the issue to an IDE warning that will have to be ignored globally, with the same result of poor code quality.
I was under the assumption that this warning was indeed reported by the compiler even before, but was filtered out by the Unity console for fields with the attribute [SerializeField]. At least that could still be done somehow, I am quite convinced. Of course we cannot expect the Unity team to modify the compiler for this, but there should be something possible on the Unity side of this.
I really would appreciate this to be tackled. Thank you very much for your effort!
Iâd also like to see this problem fixed.
I canât add much to the good points which have already been said in this thread⌠itâs just a toss-up between using the recommended way + OOPâs best practices, and making everything public to avoid an incorrect warning.
I imagine that after 2018.3 goes out of its beta stage, a couple more complaints about this will pop up since this is a problem which will likely be present in most mid to large-sized projects.
I just updated an Asset Store package and had to open twelve files just to slap #pragma (âŚ) at the top. It makes absolute sense for a third-party code â and far from only that â not to expose all the variables, yet this encourages it, as itâs the simplest solution. The other option is to hide a useful warning in order to avoid a few false positives â and I donât really think the âproperâ way to write a Unity component should contain a step such as: â2) Write a preprocessor directive to disable inevitable warningsâ.