Add support for .net standard to project

grofit commented 6 years ago

Unity recently mentioned in an article on .net update that ideally libraries for unity should be targetting .net standard profile:

The .NET Standard 2.0 profile matches the profile of the same name published by the .NET Foundation. This is a great profile to choose for a new Unity project. It is smaller than .NET 4.x and we recommend it for size-constrained platforms such as mobiles. In addition, we’ll make sure this profile works on all platforms Unity supports. If you are a developer of libraries used with Unity, this is the profile you want to target.

Given the nuget version of the project is out of date, and unity are going to be slowly phasing out the old runtime now would be a good time to update the nuget project and add .net standard support in. I would probably also suggest dropping support for anything < unity 2017 as you have older releases for that, it would make the code base simpler to maintain and build.

If it helps I have made a branch which is a large re-work of the codebase which is still not entirely finished but supports .net standard, has full test coverage with xUnit and has split the projects into a purely .net layer and a unity layer:

https://github.com/grofit/unirx/tree/pure-dotnet-and-namespaces

RDeluxe commented 6 years ago

Nice work !

It would be nice to know if @neuecc gives you the greenlight 👍

grofit commented 6 years ago

Tbh the fork is just a proof of concept I think it is more something that could be used as a basis, ultimately not much needs to change I think to support .net standard in unity, the main issue is getting unirx to consumable as a .net standard dll which would make it consumable on any .net platform (also why I have some appetite to resurrect the nuget package version). I think Unity allows this via those assembly definition things but its all a bit woolly at the moment and going forward I think there is some appetite from unity to move shared libs to pure C# projects that expose dlls rather than C# files in unity, the problem then becomes how to manage the myriad of different versions needed for different platforms etc (i.e AoT) which are currently handled via pragmas.

laicasaane commented 6 years ago

With Unity 2018 supporting .NET Standard 2.0, I wonder if we could just use the official dotnet/reactive along with the UnityEngineBridge or not?

grofit commented 6 years ago

This was discussed in the channel a bit, problem is:

System.Reactive v3.* dont seem to work in unity and version 4 is on hiatus at the moment, see their issue log for more info
Performance and GC is a lot worse in System.Reactive code (I have not seen this for myself but this is one thing a lot of people mention when it comes up in conversation
I dont think its simple to extend Observable so UniRx would have to have some other UnityObservable or something, I had to solve this in the branch I created above but even then its not ideal

I would love for this to be the case as then the amount of maintainable code shrinks, and I think it was even mentioned in another issue on here, but at the moment we are just waiting for UniRx to update or System.Reactive.

Xerios commented 6 years ago

Things seem to be working nicely using System.Reactive, although I do have some issues with AOT and System.Reactive.Linq which I assume are due to this static var: https://github.com/dotnet/reactive/blob/master/Rx.NET/Source/src/System.Reactive/Linq/Observable_.cs

Xerios commented 6 years ago

Also, I discussed briefly with the devs of RxNET, and here are some things worth mentioning:

System.Reactive 4.0 is out, and the community has finally gathered back up
According to them, performance and GC shouldn't be any worse. As a matter of fact, UniRx was based on old System.Reactive structure, along with their old architecture which has improved a lot since then.
System.Reactive 4.1 is the next version they'll be pushing out, with the goal of further improving performance.

grofit commented 6 years ago

Well if you at happy enough with the new rx.net 4.* working on most devices I have a partial rework into pure .net that I can convert into some sort of rx.net for unity or something, the main task would be:

Remove anything that already exists in rx.net
Isolate Scheduler related functionality for unity
Make sure all unity specific functionality consumes System.Reactive based classes
Make sure extension methods target System.Reactive classes wherever needed

There is one thing I think most people would like to keep and that is an Observable instance that basically exposes the common System.Reactive and unity specific methods in one place, i.e Observable.EveryFrame. This was a hassle when I was trying to map over to a pure .net version as in unirx Observable was a static partial which was basically getting appended to all over the shop, and I expect something similar in rx.net. To work around this in mine I converted the unirx version to a class with static methods and just inherited a new Observable in the unity namespace which added the custom bits in, although in this scenario it may need to be more of a facade, where we create it like that but just wrap all the underlying calls to system.reactive.

Anyway I am happy to put in some of the work on a prototype if there is some appetite for it based on my .net standard port, but in terms of testing etc I could do with some of you guys to help out there.

I would also say that it may be worth splitting out certain things into other packages, like ReactiveProperty, ReactiveCollection, ReactiveDictionary, IMessageBroker etc all of these structures are great and would help people doing game dev in regular .net (i.e monogame, godot etc) so maybe that could go into some other package separate to the unity one.

Xerios commented 6 years ago

I think it would be best to start with System.Reactive rather than basing on UniRx. And afterwards port the unity specific functions, which should be pretty easy.

Like I said, if AOT fails compiling certain functions such as Linq namespace ( which contains a lot of necessary functions like SkipUntil TakeUntil ) then there's a high chance it will also fail compiling on various platforms, like WebGL in my case.

When I say failing to compile, I actually mean that the functions aren't parsed. So what I end up with, are some errors the moment SkipUntil, Repeat or any of those Linq functions are executed. It's worth pointing out that even with errors, it still compiles but with missing functions.

grofit commented 6 years ago

Sounds good, keep us up to date with progress as I would love to just rely upon rx.net and just bolt on this unity stuff!

Xerios commented 6 years ago

Making System.Reactive AOT compatible appears to be quite challenging, especially when I'm lacking a huge portion of knowledge and experience with AOT/IL2CPP. I'll seek some help on the official rxnet slack channel.

ledvinam commented 6 years ago

Hi, I try to understand what you are talking here about but I'm not much wiser after I read all. So simple question any ETA for Netstandard 2.0 support?

grofit commented 6 years ago

Unless @neuecc himself gives you an ETA there isnt one, currently @Xerios is investigating if we even need Unirx any more as we can potentially use rx.net as the basis then add the unity specific stuff on in a new library (or this one if the maintainer decides to go that route and add more maintainers)

Xerios commented 6 years ago

There's no ETA on standard 2.0 support since neuecc lost motivation to continue working on this ( according to his blogpost ). Although he may come back, it's hard to tell, UniRx isn't his only project and it's understandable.

We might not get any additional changes anytime soon. You might've noticed that there were no proper updates for months! UniRx already works with Netstandard 2.0, so I don't see what you can get out of it.

I've tried porting Rx.NET over few days to something AOT-compatible, but every time I would end up having to remove or modify more and more features that made Rx.NET better than UniRx, eventually ending up rewriting a lot of features. Issue is mostly related to the AOT compiler that Unity currently uses, hopefully Unity devs will switch to CoreRT for their AOT compiler, which would fix most issues and allow Rx.NET to be compiled to IL2CPP properly.

Porting Rx.NET to AOT-friendly version is definitely not a one man task, and the effort will completely go to waste once AOT improvements have been implemented.

For now, the best thing to do if you need to use IL2CPP-restricted build, is to continue using UniRx. It is functional and has most Rx functions implemented. If you're building for non-IL2CPP platforms such as standalone builds, then you can use RxNET directly without any issues.

ledvinam commented 6 years ago

Do you really mean it "UniRx already works with Netstandard 2.0"? When I switch to NET 4.x backend and Netstandard 2.0 I get few errors. How should I understand what you stated above?

Thanks, Marek.

Xerios commented 6 years ago

I've just tried it with an empty project and I don't. I've been developing using NET 4.x + netstandard 2.0 + UniRx for months now and I've never encountered any issues.

You could fork this repo and fix your specific issues yourself, but seeing the lack of activity in the Pull Requests section, I doubt anything would be merged back into this repo anytime soon.

ledvinam commented 6 years ago

Hi, I had to add on few places NET_STANDARD_2_0 preprocessor. Especially there where there was defined NET_4_6 or NETFX_CORE. Can anyone fix it in repository please? Marek.

ledvinam commented 6 years ago

To be precise it is in files FromCoroutine, TaskObservableExtensions, Tuble, IProgress, IObserver, IObservable, AsyncSubject, CancellationDisposable. Hope it helps, Marek.

Xerios commented 6 years ago

Create a new issue describing your bug with a way to reproduce, then wait forever in despair because no-one will come to rescue you 😀

There hasn't been a single update since December... Your best luck would be to see if one of the 25 pull requests or any of the 390 forks actually contains the fix.

In any case, as for me, I moved on to pure RxNET, so godspeed brave soul, godspeed.

ledvinam commented 6 years ago

Well just compiled Built Unity Android and all works :-) So no issue with that only that perprocessors NET_STANDARD_2_0. I fixed my version and I guess I won’t be updating long time.

You have workable RxNET? with that Unity extensions on top of it?

Can you share?

On Jun 17, 2018, at 10:14 PM, Sam Megidov notifications@github.com wrote:

Create a new issue describing your bug with a way to reproduce, then wait forever in despair because no-one will come to rescue you 😀

There hasn't been a single update since December... Your best luck would be to see if one of the 25 pull requests or any of the 390 forks actually contains the fix.

In any case, as for me, I moved on to pure RxNET, so godspeed brave soul, godspeed.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/neuecc/UniRx/issues/300#issuecomment-397885447, or mute the thread https://github.com/notifications/unsubscribe-auth/AcnLooDnhttt09c6soSoRbx8Ws3k6f5lks5t9nJDgaJpZM4TEkeM.

Xerios commented 6 years ago

Rx.NET works with Unity, read my comments. Any build that requires IL2CPP, doesn't.

ledvinam commented 6 years ago

I see then I stick to UniRx since it is compilable after my fix also with il2cpp. :-)

Cheers.

On Jun 17, 2018, at 10:20 PM, Sam Megidov notifications@github.com wrote:

Rx.NET works with Unity, read my comments. Any build that requires IL2CPP, doesn't.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/neuecc/UniRx/issues/300#issuecomment-397885890, or mute the thread https://github.com/notifications/unsubscribe-auth/AcnLoqjoBzkAlm9V1L7kCtkl6SnjTZXQks5t9nOtgaJpZM4TEkeM.

grofit commented 6 years ago

@Xerios Any further news on this? and is there any issue on the rx.net board around anything they can do to improve this use case?

Xerios commented 6 years ago

Current Rx.NET bases on a lot of features that aren't supported with AOT, and making it AOT compatible means that you'll have to rework on almost half of the codebase. No wonder why neuecc started from scratch, converting the whole library is not an easy task, and keeping it up-to-date will be even harder.

Me personally, I'd wait until Unity team improves their AOT compiler.

grofit commented 6 years ago

Is this something on the roadmap (unitys), and if it is will this hopefully mitigate the problem?

I am in a tricky spot as at the moment I need to support users of unirx and rx.net within the same codebase, and atm I am having to create a tiny rx implementation to satisfy the basic internal stuff and let the consumer pick which one they want to use, but its getting more and more painful to add new features without access to one of the given libs.

dzmitry-lahoda commented 5 years ago

@Xerios , could you point some exact classes in Rx.NET (preferably core classes) which work bad with AOT?

Reflection Emit - totally disallowed
Expression LINQ - possible in AOT, but better to avoid because interpreted
Reflection MethodInfo Delegate.Create should work fine with link.xml. Still may try to avoid reflection.

dzmitry-lahoda commented 5 years ago

I did https://github.com/Xerios/AdvancedCameraControls targeting Android IL2CPP. Seems link.xml may help. Does not looks like code generation is used, just some delegate invocation(which should work, or this is a Unity runtime issue).

11-19 15:16:33.711  6589  6608 E Unity   : ExecutionEngineException: Attempting to call method 'System.Reactive.Linq.QueryLanguage::Multicast<UnityEngine.Vector2, UnityEngine.Vector2>' for which no ahead of time (AOT) code was generated.

11-19 15:16:33.711  6589  6608 E Unity   :   at InputManager.OnEnable () [0x00000] in <00000000000000000000000000000000>:0 

11-19 15:16:33.711  6589  6608 E Unity   :  

11-19 15:16:33.711  6589  6608 E Unity   : (Filename: currently not available on il2cpp Line: -1)

11-19 15:16:33.711  6589  6608 E Unity   : 

11-19 15:16:33.714  6589  6608 E Unity   : ArgumentNullException: Value cannot be null.

11-19 15:16:33.714  6589  6608 E Unity   : Parameter name: source

11-19 15:16:33.714  6589  6608 E Unity   :   at CameraController.OnEnable () [0x00000] in <00000000000000000000000000000000>:0 

11-19 15:16:33.714  6589  6608 E Unity   :  

11-19 15:16:33.714  6589  6608 E Unity   : (Filename: currently not available on il2cpp Line: -1)

11-19 15:16:33.714  6589  6608 E Unity   :

Xerios commented 5 years ago

Been a while since I dived into this, but as far as I remember, a lot of code related to schedulers wasn't compatible, lots of auto-generated LINQ wasn't compatible and some other things. There were some totally readable code that didn't get compiled to AOT which made things even more confusing for me. Neuecc found some rather weird but working solutions to those problems, and there were many of those around, to a point that justifies UniRx existence.

I've seen that AsyncRx.NET has been shaping itself up quite nicely, has anyone tried it with AOT ?

dzmitry-lahoda commented 5 years ago

Rx.NET has some interesting directive, which seems used to close generics:

#if CRIPPLED_REFLECTION
                    InfoOf(() => And<TLeft, TRight>(default, default)),
#else
                    ((MethodInfo)MethodBase.GetCurrentMethod()).MakeGenericMethod(typeof(TLeft), typeof(TRight)),
#endif

grofit commented 5 years ago

I have pinged in the rx.net thread too but did either of you get rx.net working in unity IL2CPP (with link.xml or whatever other stuff is needed)? @Xerios @dzmitry-lahoda

Xerios commented 5 years ago

Nope, given up on this long time ago. I've been moving away from reactive extensions recently, in favor of pure C# and DOTS ( Unity's ECS ).

Once async streams (C# 8.0) lands in Unity, I can only imagine this library becoming redundant.

grofit commented 5 years ago

but even with IAsyncEnumerable wont there still be a lot of lacking functionality which would need polyfilling from somewhere? as the notion of IObservable is just one part of reactive extensions, the main benefit to most people is the rich functionality it adds to IObservable like linq to IEnumerable.

Also wouldnt there be a fair bit of overhead having to use async everywhere? as the IObservable approach is synchronous in execution right? (I would love to pick your brains more on this if you are on the unirx gitter or slack/discord etc)

dzmitry-lahoda commented 5 years ago

I was not able to run Rx.net on IL2CPP, but guess that possible with some effort. We use UniRx above kind of custom ECS like stuff now. If we would have end to end ECS, than we could omit RX in realtime battle part (like trigger heal animation). But still RX is good for meta part and other meta like elements in above battle window (like chat messages).

Give RX is not well composed with structs-ref-in (which we use heavily in our ECS like with C# 7.3) and given other updates in C# 8.0 - than RX makes less sense for realtime battle part. We do not plan DOTS as we run part of ECS code on server in .NET Core process (simulation).

But for meta part (like shop-train-upgrade), RX seems good to handle speculative execution on top of immutable state (events and rollbacks). And non ECS(casual?) games overall seems could fit. As of now RX does help with matchmaking (calls are async, but match making is RX sync like callback). Meta UI still can be done in ECS, but there may be caveats (i.e. cannot hire usual GUI developer to do the task) and may appear more complex that with RX.

I think Async and RX are composable approaches, kind of orthogonal. Async is cheaper now with ValueTask (and other optimization could be done in custom awaiter could be done - there are articles). There is System.Threading.Channells to do cooperative multi threading.

Rx.NET still needs to be ported with some Unity integrations from UniRX (like resource management and routing callbacks into main thread).

Also there are couple of issues raised to Unity LINQ in IL2CPP by me and other person for Unity 2018.2+ as I recall. May be fixes could help in future either.

grofit commented 5 years ago

Most of my use cases are for callback scenarios not async processing,

i.e when X occurs on a stream notify me and do something

Which isnt really a good fit for IAsyncEnumerable as really im just going to have a foreach loop to call a method rather than a succinct Subscribe(DoSomethingWithData);, due to the push vs pull nature of stuff.

The possibility of removing huge chunks of UniRx and just making it an extension on rx.net has been an ongoing conversation point for a while but until rx.net supports unity as well as unirx its impossible to make the move over.

Much like your scenario I run stuff outside of unity and have a unity layer which adds the unity specific stuff in, but in the unity world I need unirx, and in the <any other .net scenario> I need rx.net so ideally I just want to depend upon 1 rx implementation and use that everywhere be it in unity or on a headless simulation (or even in a browser via Electron.Net + Blazor etc), but as you say someone needs to do some work to make this happen.

Between everyone who has been involved to date so far can you give a breakdown of the work involved to get rx working with il2cpp? i.e what specifically breaks and why?

dzmitry-lahoda commented 5 years ago

There are several things that do break(and my comments about Rx.Net):

LINQ expressions interpreter (i have not seen it is used, only usual expressions as reflection; no Compile, only parsing; but pattern kind of complex)
IL Emit (not used)
Unsafe code (have not seen)
AOT compile out (used link.xml as much as possible)
Unity does not fully comform .NET Standard 2.0 (may be LINQ trees, may be other stuff)

It is matter of time for me to find root cause (like it was with MessagePack or SignalRCore or Json.NET), but because we do not use(yet) Rx.NET, I am so not (yet) motivated. And (very bad stuff), non of Rx.NET maintainers responded(yet) in thread (supporting us or asking for pull or putting tag) https://github.com/dotnet/reactive/issues/848, so we have risks not getting into mainline with pull, even if done. And another risk - somebody should port Unity specific parts on top of Rx.NET(so may be somebody already ported as JIT Mono works).

grofit commented 5 years ago

Ok so what I would propose here so we can get as many people working towards same goal would be to create a standalone repo which anyone can run and shows the current problems faced with rx in unity.

I am happy enough to create the base repo, but I could do with some guidance as to what I should be putting in there and what platforms/settings I should be building for, this way any of us can clone it, run it with any version of rx and see what issues there are and try to tackle each one with the rx guys.

So as a stab in the dark I assume I will need to:

Create repo with Unity 2018 + rx.net 4.*
Invoke as much of rx.net as is possible (could do with some guidance on this)
Make sure it all runs in the editor without error using .net 4.x version (and potentially .net standard)
Create builds for all(?) IL2CPP platforms (again could do with guidance here)

Is that enough to use as a baseline? as my hope is if we can get a broken project which we can all reproduce, then work out what bits are the problem and see what can be worked around, then whatever cannot be worked around we can at least isolate it, take it to the rx guys and see if they can realistically help out, with the repo as their reproduction point.

I will get a repo setup asap for it but I dont have any physical devices other than the PC I am using here, so I am not sure if I NEED actual hardware to create the IL2CPP builds, that whole part of this is the biggest unknown for me as I have never needed to build for anything other than PC before.

The Repo

https://github.com/grofit/unity-rx-test

Here is the repo I am using as a basis to try to isolate all this stuff, if anyone can advise on the queries above it would be great.

dzmitry-lahoda commented 5 years ago

Another approach could be:

Run Xunity on IL2CPP (yep, I does not runs here out of box, I have tried to solve it, woudld RX team allow patches if they cannot run tests on target platform? ).
Create Unity project to run all or some relevant tests from https://github.com/dotnet/reactive/blob/master/Rx.NET/Source/tests/Tests.System.Reactive/Tests/.
Go through each test - a. should run b. not relevant c. should fix test d. should fix rx .net

As for running on devices, I have run on Android (seems have save issues as iOS).

grofit commented 5 years ago

running the tests is a brilliant idea! I will see if its easy enough to get them in and running in the editor, then will look at targetting different IL2CPP platforms and see what blows up.

== Update ==

After speaking to some of the unity team they have mentioned that you can run tests against varying platforms but it seems you need the actual hardware to run them on, and I haven't got any devices other than this laptop that I can run it on :(

I can at least do the work though to map them over to use Nunit and have them run in the unity test runner in the editor, then its just a case of finding willing participants who have iOS and other platforms to run the tests and see what they get back.

grofit commented 5 years ago

Current Results

Right I have put the repo up for anyone who fancies trying to look at whats breaking and how to fix it.

Currently running in default mono mode out of 3600 total tests we have:

✔️ 3033 ❌ 567

https://github.com/grofit/unity-rx-test

I was running the tests via Rider test runner (as it can run them in IDE even if you use unity stuff), the tests have been ported over to use nunit and there are the required dlls in place for the tests to run (as the tests rely upon several other dlls the main runtime doesnt).

Update 1

Ok so I was incorrectly using Assert.Equals rather than Assert.AreEqual so now the test results are:

✔️ 3586 ❌ 14

Update 2

Have fixed issues with default not resolving correctly in nunit, so this moves it to:

✔️ 3592 ❌ 8

Remaining issues are ordering based, Observable class member check and some Task related tests

Update 3

Have tried running from the source, and the ordering tests pass there, so something seems amiss with the dlls that I am using (netstandard versions from nuget), so not sure whats going on there. Also worth noting that if you are running the tests in rider WITHOUT unity runner, you get the above 8 failures, if you run it through unity test runner you get about 35 failures, the newer ones being due to it unable to access the dll generated by the unity project.

Any help would be great in solving the remaining 8.

Update 4

After discussing it within rx slack channel I have made an isolated new corenet app outside of unity, got the latest (4.1.4) rx netstandard versions of the assemblies (like in the unity version), have taken the same tests over and they fail the same (although the 3 last async based ones dont fail) but the ordering fails the same, so I think this is not a unity specific issue, but hopefully this will give an avenue to get them fixed or ignored.

Whats next?

So if anyone has the time it would be great if you could clone it, check over the broken tests and see if they are valid, and if so are they breaking for a real reason?

If we can get a full suite of green tests in editor/mono running, then we should be able to look at moving to IL2CPP targets and running them there and seeing what breaks, but until we have all greens it seems risky to start trying to run against the IL2CPP stuff.

RDeluxe commented 5 years ago

The results look better than I expected !

grofit commented 5 years ago

Remember that this is just running in the editor at the moment not in IL2CPP, I just want everything green first then we can look at IL2CPP and other niche scenarios. In terms of current problems I am trying to chase up with the rx chaps why tests fail with wrong order, but not getting much traction there, if anyone wants to help out feel free to jump on their slack or do your own investigations, PRs are welcome.

dzmitry-lahoda commented 5 years ago

how can i run unity nunit tests on device? i have not found definitive answer. i would run them than here than.

grofit commented 5 years ago

I asked about this in the unity devs slack channel and was told you can do it, if you look at:

https://docs.unity3d.com/Manual/PlaymodeTestFramework.html

And then "Running tests on platforms" it shows you what you can do to run them in playmode on other devices.

There is a small amount of traction in the rx slack channel around why the remaining 8 failures happen (and there are about 25 other failures you will get when you run it through unity test runner rather than through a normal nunit runner, but those are unity specific and probably can be fixed later).

grofit commented 5 years ago

Right after many conversations it appears that I should not have been running master branch tests, as there was a specific rel 4.1 branch which had more tailored tests, some still not passing but checked and we seem fine to remove them so now all tests pass.

✔️ 3592

This being said there are still issues when running it with the unity test editor where it says you cannot access the project dlls so going to look into that when I have time.

is it also worth moving this conversation over to https://github.com/grofit/unity-rx-test as this is slightly off topic now for unirx.

https://github.com/grofit/unity-rx-test/issues/1

shanecelis commented 5 years ago

It seems we are all having similar notions of where to go. I updated issue #324. Briefly: I made some headway in getting an unmodified System.Reactive.dll to work in Unity much like @grofit has. I hadn't seen his work. Running the test suite is a brilliant idea! In addition, I got it working on AOT platforms. I have a prototype that you can examine and try out. You can see the iOS app in action here. It is ugly as sin but demonstrates that System.Reactive + UniRx might be a worthwhile approach to acquiring all the operators and possibly lessening UniRx's support burden.

grofit commented 5 years ago

Hey great job, I'm partially on holiday atm so not on computer much atm, sounds like major progress.

Is the next step to get the current implementation provided tested on other platforms?

Ideally I guess we need to confirm all Unirx platforms are supported then look at how to best package this all, as from what I have read of your work so far we don't touch system.reactive, we just drop in the new dlls.

This approach is perfect for my scenario as ecsrx is getting harder to maintain and add features to without being able to target system.reactive or Unirx directly in the core :(

SiriusA7 commented 5 years ago

@shanecelis I converted and built out your ios prototype to my oculus quest (android) and it seems to work fine with both mono and il2cpp. Here's a quick video of it working in the headset: https://imgur.com/a/LKo57nA

shanecelis commented 5 years ago

Thanks, @grofit. Testing it on other platforms is a good idea. And yes, I didn't touch System.Reactive.dll at all. Glad to hear this could be useful.

That's great to hear, @SiriusA7! So that means Android works, right?

I tried out macOS il2cpp and that works too. I copied the Scripting Restrictions page of platforms to a google spreadsheet that anyone can fill it out.

My time window to work on this is going to be narrowing, but I'll try to keep abreast of what's going on. I'll add some more information on how I got the needed AOT type information when Unity isn't forthcoming with those details on the platform directly.

SiriusA7 commented 5 years ago

@shanecelis, as far as I can tell! The Quest is the only android device I have. I targeted android minimum api level 21 if that makes any difference. It worked fine with oculus integration, no errors came up at any point in the console.

I also managed to do a successful UWP il2cpp build out targeting the HoloLens with MRTK. No errors when I tested in editor and no errors when built out. Haven't deployed and tested on the headset yet, but I don't foresee any issues coming up. Will test on device soon and update the spreadsheet when it's confirmed.

grofit commented 5 years ago

Just to confirm, when we are testing this on other platforms are we testing the majority of rx (i.e the rx.net unit test suite) or are we just testing a few of the methods directly?

shanecelis commented 5 years ago

Just the attempt 4 method. It’s a very low bar to clear. I added a column for unity-rx-test where we can record pass and fail counts.

neuecc / UniRx