Search Unity

  1. New Unity Live Help updates. Check them out here!

    Dismiss Notice

disable plugin only warnings

Discussion in 'Scripting' started by sebas77, Jul 26, 2016.

  1. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,121
    Hi,

    is it possible to disable all the warnings of the source code under a specific folder? Some the libs/plugins we use are outdated and the warnings are pestering us.
    I tried to use the smcs file, but it apparently cannot be specified per project (it would have been awesome and technically possible since the plugins are compiled to a different dll)
     
  2. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,121
    I'd like to bump this one. I really need to disable the warnings only for the Plugin folder, am I the only one to have this problem?
     
  3. Rob21894

    Rob21894

    Joined:
    Nov 21, 2013
    Posts:
    309
    I know in script, you can disable warnings using #pragma for c#

    Code (CSharp):
    1. #pragma warning disable xxxx // the number of the warning
     
  4. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,121
    that's true, but the plugin folder is made of source code that has not been written by me. It's usually about libraries that get obsolete over the time and they are not always updated.

    I know that what I want is actually not possible at the moment, I just wonder if it wouldn't be wise for Unity to add the option to have compiler options per project, since it's technically possible.
     
  5. Rob21894

    Rob21894

    Joined:
    Nov 21, 2013
    Posts:
    309
  6. sebas77

    sebas77

    Joined:
    Nov 4, 2011
    Posts:
    1,121
  7. Agustin-Petrini845

    Agustin-Petrini845

    Joined:
    Oct 27, 2012
    Posts:
    2
    Any news on this at all?
    I wonder how this is not a bigger issue. Having a 0 warning policy is a recommended practice.
     
    sebas77 and phobos2077 like this.
  8. Lurking-Ninja

    Lurking-Ninja

    Joined:
    Jan 20, 2015
    Posts:
    4,645
    Recommended by whom?
     
  9. Gladyon

    Gladyon

    Joined:
    Sep 10, 2015
    Posts:
    230
    A lot of people, me included.
    Even if we all know that about 999 out of 1000 warnings are completely useless.


    We'll take a common example, something most dev will probably recognize.
    You add some code, and at some point you make a mistake (we all make a mistake at least once), for the sake of the example, say that it is one of these mistake which produce a warning.
    So, no problem, you immediately see the new warning and fix it, no problem.

    Now, if you have 2157 warnings, all of them being not a problem because they just warn you about unused fields (for example).
    Then, you cannot see the new warning, because it's in the middle of 2157 useless warnings.
    So you miss it.
    And if you do not have very thorough tests, you may even miss the mistake (I'm pretty sure it has happened to about all of us at least once).
    At that point, it may take a few days/weeks/months before you finally see the bug, especially if it's one of these bugs which is a bit shy and doesn't like to show itself until it's ready to do the most damages.
    If the mistake was to declare a 'Awake()' function in a class inheriting from another class which inherit from a MonoBehaviour without 'override', then the compiler tells you about it and warn you to either use 'override' or 'new'.
    That type of mistake is common, and not easy to see if the parent 'Awake()' method does nearly nothing.
    In some situation such a bug can be very hard to find out and may take a few hours to fix.
    These hours aren't really the problem, the worse is that they are frustrating hours because (as often), there's no reason that the code you add in the 'Awake()' method doesn't work.
    And even worse, when you finally fix the bug, your brain cannot avoid telling itself that it could have been avoided by reading the warning indicating the problem, which made the mistake a very stupid one in the first place, definitely not worth spending hours on it.
    So, for a few hours after having fixed the silly bug you are frustrated and irritated, which leads to more mistakes... and to more lost hours... and to more frustration/irritation...


    Having 0 warning simply ensure that you see the new warnings as soon as they are created.



    As for the OP, I think we should be able to disable warnings for entire assemblies using the .asmdef files.
    I always have to fix the warnings of the asset I use, which end up not being very interesting because I do not really care about the bugs in the asset as I'm not planning to fix them.
    Being able to remove the warnings from .asmdef files would make it very easy to remove/enable any warning from the assets by just placing them in their own assembly (if not already done by the author).
     
    phobos2077 likes this.
  10. phobos2077

    phobos2077

    Joined:
    Feb 10, 2018
    Posts:
    88
    Any progress on this issue? Anyone knows workarounds? I've got a third-party commercial asset in a project which is distributed as a pre-compiled managed DLL. It spams the same warnings over and over which I'm not very interested it (because devs of this asset are sloppy and never heard about different Cultures when formatting numbers...). This asset is not updated anymore btw.
     
    EyePD and SarahStief like this.
  11. EyePD

    EyePD

    Joined:
    Feb 26, 2016
    Posts:
    57
    +1; I'm trying to enforce no warnings on my code but I don't want to address warnings in third party code (nor do I want to modify it with pragmas)
     
  12. Joe-Censored

    Joe-Censored

    Joined:
    Mar 26, 2013
    Posts:
    7,769
    I'd just like to point out that suppressing warnings is counter productive to a "no warnings" policy. That's like fixing your car's check engine light by cutting its wires. Look the car isn't warning anymore! The point of a no warnings policy is to actually fix all the warnings, otherwise the policy is pointless.

    If the policy isn't compatible with your 3rd party libraries, and you have good reason to continue using them, then the policy is what should be changed, as down the line the issue the warnings were warning you about may actually bite you, and you can thank suppressing the warnings why no one realized it would happen. My opinion at least.
     
    Last edited: Mar 4, 2020
  13. EyePD

    EyePD

    Joined:
    Feb 26, 2016
    Posts:
    57
    I understand your opinion but I'd like to respectfully suggest that this thread be kept to answering the OP's question. I've found similar threads that descended into all out flame wars. I'm proposing we keep this thread on the rails and work towards a solution (albeit one that adds risk). Thanks for your consideration.
     
    phobos2077 likes this.
  14. EyePD

    EyePD

    Joined:
    Feb 26, 2016
    Posts:
    57
    I think I've found a solution based on per-assembly rsp files based on this thread. I created a folder in Assets called 3rdparty and put my external code with warnings in there. Next I created an Assembly Definition in 3rdparty (from the create menu). With a text editor I created a csc.rsp file in 3rdparty and put in "-nowarn". This compiler option will only affect compilation in the 3rdparty folder. I was also able to put a csc.rsp at the top level as well and turn on "-warnaserror" so that warnings in my code will be treated as errors but warnings in 3rdparty will be ignored!

    The bad news is that none of these settings affect compilation within VisualStudio; does anyone know of a way to get that done?
     
unityunity