Compiles in Unity but does not compile in MonoDevelop about zenject-2019

[svermeulen]

Thanks for reporting this - I'm going to try changing to use overloads instead

[svermeulen]

Ok I updated the git repo to play nicely with monodevelop (using overloads). I'm not seeing your other error though about ambiguous reference. It might be fixed with the newer version of zenject (2.5)?

[marked-one]

The github version now compiles in MonoDevelop just fine.

But, the other error doesn't appear by default, you need to go to Project->Assembly-CSharp Options in MonoDevelop, choose Build->General and change Target Framework to Mono/.Net 4.0 or above. I tried and it's still there. I couldn't be sure if this is really important, though. Probably not. But some people increase the framework version for different reasons (methods with default parameters is one of such reasons).

Also found another minor issue, with cursor visibiliy in GameController of sample game. You now probably need to check for UNITY_5 (or for both UNITY_5_0 and UNITY_5_1). Otherwise, Unity automatically converts the code to:

#if UNITY_5_0
            Cursor.visible = false;
#else
            Cursor.visible = false;
#endif

Which is even already in the repo.

[svermeulen]

Ah yes I see what you mean with the ambiguous errors now. I'm not sure if there's a way to fully address that since as you say there isn't defines you can #ifdef with for the .NET framework version as far as I know. The reason that I defined those custom versions of Func<> is because .NET 3.5 or less only defines Func<> up to four parameters, which is quite limiting. But if you are using a more recent version of .NET then you can just comment those out (I added a comment in Func.cs explaining this). I had to make a few other minor adjustments but after you do that it seems to compile fine with 4.0

As for the cursor visibility, I'm not sure what problem you are referring to. I noticed that the cursor is still visible in unity but when run as a standalone build it is correctly invisible. I did remove the #ifdef though since it was pointless the way it was.

Let me know if you notice any other issues

[marked-one]

Maybe I'm a bit of unclear, since I'm not a native English speaker. The "cursor problem" was with the import in 5.1. The original code (as in the asset store version) is

#if UNITY_5_0
        Cursor.visible = false; 
#else
        Screen.showCursor = false;
#endif`

The first one is for Unity 5, the second should be for Unity 4 or earlier. But Unity 5.1 has different define UNITY_5_1 and thus chooses the version for Unity 4. And then it converts it to the same Cursor.visible = false;. So it is necessary to use UNITY_5 define or both UNITY_5_0 and UNITY_5_1. Or, as you did, just throw defines away and only leave Cursor.visible = false;, if Unity 4 support is no more necessary.

I don't see any other bugs so far. Probably could give you some criticism about the code, if you are open to it. But since my opinion could be a bit of subjective and personal, I'll better write you an email.

Nevertheless, I tried six IoC solutions for Unity (Zenject, StrangeIoC, MinIoC, Adic, uInject, Svelto) and Zenject seems to be best. StrangeIoC is too overcomplicated, Svelto is too simplified, MinIoC does strange things even in its description and examples (e.g. injection into serialized fields of MonoBehaviour), uInject propagates the use of DIMono abstract class instead of MonoBehaviour, Adic requires Inject to be called from MonoBehaviour etc. Only Zenject does what I expect from an IoC/DI framework. So keep up te good work.

[svermeulen]

Thanks :) I'm glad you're enjoying it

I see what you mean now. I'm not sure how many people are still using Unity 4 but I might as well remain compatible with it, since that's the only change required. So I've made the change you recommended.

Sure, if you have thoughts on the code I'm happy to hear them. My email is [email protected]. I've played with a few of the other frameworks you've mentioned but not very much, so if you have observed anything useful in those I'd be happy to hear those too.

Personally, my biggest gripe with Zenject is that it doesn't have very good support for nested containers. This is something I plan to address with the next release. Then after that, probably convention based binding.