Basically nothing works in Unity 2017.1b4

[Scott Richmond]

We're currently on the latest edge betas as we require C# 6 features. A great many exceptions explode everywhere upon installing the plugin. There are plenty more just browsing through the demo scenes. :/

I'd provide more info, but I think it just easier if you took a look yourself. There are no real repro steps - It just happens everywhere.

[Tor Esa Vestergaard]

Yeah, Unity seems to have changed a lot of stuff in 2017.1, and we didn't manage to update the asset store text in time to reflect this.

We're working on resolving this as fast as we can.

[Tor Esa Vestergaard]

To keep you up to date, we're currently testing a fix for 2017.1 where we disable the Odin feature that's causing trouble in that version of Unity. The feature in question is support for drawing non-Unity-serialized data with Unity's vanilla-style custom property drawers. We employ a bit of sorcery to get this done, and this broke in 2017.1. We have an issue posted with Unity; we'll see if they get around to fixing it.

If not, we do have other options, but we'd rather not resort to those if we can avoid it.

[Scott Richmond]

Cheers. In our particular case we're not too interested in the serialization features of Odin - We've rolled our own solution there - So that should be fine. We're keen to utilize the powerful drawers you guys have developed.

Just be sure to test: * All the test scenes you've got. * I tried disabling a plugin in your prefs (NodeCanvas) because it seemed there were some conflicts, and enabling Unity default types - Much broke in doing that. * I couldn't quite tell due to the above, but I have auto-recompile disabled, and I suspect Odin was expecting to see a recompile in changing options there.

[Tor Esa Vestergaard]

This issue does have some broader implications for initializing drawers in general, which would see practically everything, especially Unity's stuff, break completely. Luckily, that one is a relatively easy fix, and that is part of the testing.

[Tor Esa Vestergaard]

To give you an update, we've been testing in 2017.1, and everything seems to be working now on all scenes. We'll be doing some final testing with NodeCanvas in 2017.1 (not anticipating any trouble there), and then we'll push the update up promptly. For now, we've merely disabled the drawing of non-Unity-serialized data with Unity's vanilla custom property drawers in 2017.1.

[Scott Richmond]

Thanks for the update.

Does that mean that I won't be able to utilize Odin to display my custom types using Odin's drawers until it is fixed?

[Tor Esa Vestergaard]

No, Odin's drawers will all work perfectly fine, and you will be able to create your own Odin drawers very easily (the manual section for that isn't done yet, but you can look at all of our drawers in the provided source code to see how it can be done - it's quite straight forward).

The feature that's affected is rather niche, in a sense. Odin integrates Unity's own custom property drawers (legacy drawer support, so to speak), so if you've extended your editor with custom attributes and custom drawers and such before installing Odin, Odin will find and use those customizations in the form of drawers you've made that inherit from Unity's DecoratorDrawer or PropertyDrawer.

In 2017.1, this still works fine for all data that is serialized by Unity (so in your case, it sounds like, you ought to be completely fine). It's merely that we also ensured that non-Unity-serialized data can be drawn by legacy Unity drawers, and this broke in 2017.1. If Unity hasn't fixed the issue that's causing this before 2017.1 starts getting to the release candidates, we'll likely implement another fix we've got lined up so it will work fully in 2017.1 - it will just take some time to ensure that the fix is going to work out well, so for now we've just turned the feature off while we test the full fix.

[Scott Richmond]

Sounds good. When can I expect this work-around hotfix?

[Tor Esa Vestergaard]

We should have sent a mail with the hotfix attached - can you confirm whether or not it works to resolve your issues?

[Tor Esa Vestergaard]

Huh, that's odd. It seems like the change in the runtime has affected the access of the custom emitted serialization formatters. I'll look into this - probably default behaviour has changed and we need to specify an extra parameter. Thanks for catching this - I was sure I'd gone through all the demo examples!

Either way, this is an issue with our custom serialization on platforms where emit is possible - you should be fine so long as you don't make use of it, as you said you didn't intend to.

[Scott Richmond]

Would be good if you could resolve that error soonish however - I've found even just changing from one Unity scene to another causes a bit of error spam from the above.

Cheers. :)

[Scott Richmond]

Ignore the above - I was using the old version of Odin.

[Tor Esa Vestergaard]

I have so far been completely unable to replicate the MethodAccessException serialization error you mentioned in 2017.1 or any other version of Unity, and to my knowledge we haven't taken any steps that should have resolved it. You say that it doesn't show up any more?

[Tor Esa Vestergaard]

Additionally, for the record I should say that I just heard back from Unity QA regarding the bug in Unity that was causing all the initial trouble. It should be fixed on their end now, and should hopefully make it into a 2017.1 patch in the somewhat near future. After Unity's patch with the fix is up, we will probably enable the feature in Odin again.

[Tor Esa Vestergaard]

I'm going to mark this as resolved, as I've been unable to reproduce the MethodAccessException error you mention above - do write if the issue recurs, and I'll re-open it.

[Tor Esa Vestergaard]

I will load up that build and test it out.

[Tor Esa Vestergaard]

This does not happen for me on 2017.1.0b7 - can I ask which platform you're running Unity on, and which build target you have set in your project when the error occurs?

[Tor Esa Vestergaard]

Correction: I've managed to replicate it by switching the underlying target runtime from stable to experimental under project player settings. Looking into it now.

[Tor Esa Vestergaard]

I've identified the exact issue, and this is a bit of a tricky one, having to do with a change in how assembly permissions and security works in the newest .NET. I have a fix in mind, though, and will be implementing it very soon. It should make the next patch. Meanwhile, formatter emitting will be broken in the new .NET, meaning serialization on all non-AoT platforms will be broken.

Meanwhile, I'm afraid you have no recourse but to simply avoid using Odin's serialization with the Standalone and Android build targets until we get the fix out. Basically, so long as you ignore the demo scenes and don't inherit from any of Odin's specially serialized variants of Unity's classes, you shouldn't even see this issue.

[William William]

Thank you <3

[Tor Esa Vestergaard]

I've implemented and tested the fix on both the new and old .NET runtimes. This has now been resolved - the fix will make it into the next patch.