C#6 using static problem

Hi.
I found a editor bug that I could not add component when using using static with a namespace definition.

Code (CSharp):

1. using static System.Math;
2.  
3. namespace Test
4. {
5.     public class A : MonoBehaviour {
6.  
7.         :
8.     }
9. }

When I write the above code and try to add component to the game object, I get a dialog box saying that the script class can not be found.

 

Same here, I use version 5.6.1f1, with the CSharp60Support package.
Everythings else work like a charm except this.
Any help would be appreciated.
Thanks.

 

This is also the case with the current experimental .net 4.6 on Unity 2017.1.0
Adding any using static directive before a MonoBehavior definition will cause Unity to no longer see the class as a MonoBehavior.

 

Same here,
2017.3.1p3

 

@JoshPeterson I don't know if I find the time for this to isolate, but I think what @dungeonkim wrote is already enough in an empty project with experimental 4.6 enabled:

1. 
   
   Code (CSharp):

   1. using static System.Math;
   2. namespace Test
   3. {
   4.     public class A : MonoBehaviour {
   5.         :
   6.     }
   7. }

 

I'm having this problem in 2018.1 beta 13.

Something like the below will work.

Code (CSharp):

1. using UnityEngine;
2. using static UnityEngine.Mathf;
3.  
4. public class Tester : MonoBehaviour {
5.    
6. }
7.  

However the below does not.
Basically namespaced MonoBehaviours are broken

Code (CSharp):

1. using UnityEngine;
2. using static UnityEngine.Mathf;
3.  
4. namespace DeathByNamespace
5. {
6.     public class Tester : MonoBehaviour
7.     {
8.        
9.     }
10. }
11.  

 

@JoshPeterson I found this besides @Moncader_GREE providing a validated test case:

https://issuetracker.unity3d.com/is...ses-unity-to-not-find-the-class-in-the-script

I guess it's still in the process of being implemented into a future release.

 

I is not just "using static" it also happens when get-only properties are defined in custom component implementation file.

 

same problem here in Unity 2018.1. "using static" directive makes Unity no longer see MonoBehaviour script; Project uses .NET 4.*

 

Hey @JoshPeterson

I confirm the issue on Unity 2018.2.3f1 with (or without) the latest Incremental Compiler.
The problem seems to be with using static imports in types that are in a namespace.
Types without namespace mostly work.

I say mostly because you can still break the parser, but I found no consistent way of doing that.

Bug report # is 1069915

 

This happens randomly with regular scripts for me aswell (no static using). But i also cannot reproduce it consistently (but when it happens, the 'Namespace' field in the debug-view inspector is empty).

 

Yeah, I saw more people reporting the same issue with 2018.2.3 here on the forums.
One guy reported that adding a space before the colon when inheriting from MonoBehaviour-derived classes fixed the issue for him (!)

Like, SomeBehaviour : MonoBehaviour works, but SomeBehaviour: MonoBehaviour breaks the parser.
I didn't test it because I'm not using .2.3 anymore.

 

I also have a similar problem, but mine is about incorrect evaluation of #if preprocessor directives and Unity not seeing my MonoBehaviour script in a namespace behind that #if:

With BUILD_MY_APP being a custom define symbol / preprocessor directive only under standalone build (and not WSA build) and with standalone build being active/selected...

This doesn't work (script could not be loaded):

Code (CSharp):

1. #if BUILD_MY_APP && (UNITY_WSA || UNITY_STANDALONE)
2. namespace MyCompany.MyProduct
3. {
4.    public class MyClass : MonoBehaviour
5.    {
6.       ...
7.    }
8. }
9. #endif

However this does:

Code (CSharp):

1. #if BUILD_MY_APP && (UNITY_STANDALONE || UNITY_WSA)
2. namespace MyCompany.MyProduct
3. {
4.    public class MyClass : MonoBehaviour
5.    {
6.       ...
7.    }
8. }
9. #endif

Notice how the only thing changes is the order of the Unity's preprocessor directives / define symbols, which is nonsense because these two expressions should clearly produce the same result.

I think Unity under the hood parses the preprocessor directives in a way that simply doesn't cover all edge cases and makes certain assumptions about the built-in (UNITY_) directives. This is also a regression, as all our scripts loaded correctly in an older version of Unity (I can't remember which).

Finally, this code works (which is our current workoaround for our multi-app and multi-platform project setup):

Code (CSharp):

1. #if BUILD_MY_APP
2. #if UNITY_STANDALONE || UNITY_WSA
3. namespace MyCompany.MyProduct
4. {
5.    public class MyClass : MonoBehaviour
6.    {
7.       ...
8.    }
9. }
10. #endif
11. #endif

I submitted a bug but I can't really find it. By the way how can I see the bugs I've submitted?

Update: bug report 1080696

Cheers

 

When you submit a bug, you'll get an email notifying you about the bug #, and a link to a page containing that bug report and all other bug reports you have submitted.

The first email usually shows up after 1-2 minutes, and is an automated email telling you that it's been received. Then, when it's handled, you'll get an email - usually just saying "we confirmed the bug and sent it to our developers for resolution", or a follow-up email asking for more info. That can take everything from hours to weeks.

 

I see this bug was fixed in 2018.2.2f1. Can we get this fix in 2017.4?

 

Any word on fixing the thing? Using Unity Pro 2018.2.6f1 and still getting this bug. Pretty please, we need namespaces and long full qualifiers are not a viable option here.

 

Thank you for replying so quickly.
Bug report sent a few days ago. Today I've sent a basic demo project.
I'm putting the link in here as well:
https://we.tl/t-Im9xWvGYVg

 

With the assistance of Unity people at bug reporting - thank both you and them - I can confirm that the bug is solved and not present in Unity 2018.3.