4

First of all, I've posted a similar question on answers.unity.com and after realized it's affect a way broader community... so please did not take this as a crossposting.

Deploying C# code to IOS recently became a nightmare for me. All started with an ExecutionEngineException when I tried do deploy my game to the IPAD, and I used a mature well unit tested assembly of mine.

In past the few days I did my homework, and discovered the dozens of ExecutionEngineException related questions. As I learn there is no magic solution here, only to workaround the specific code.

Now here is the problem: Suppose you have a well unit tested code. (for example a game AI or anything which is not related directly to the IOS platform) This will turn to a minefield when running on IOS. You can not know, nor unit test which part of code will break.

This ruins all my (our?) ideas about software quality and testing...

We must find a solution here. Ideally we should run AOT-ed code in desktop against its unit test. I think it is not possible currently, please correct me if I am wrong and share a step to step instructions how to do it (preferably in Windows?)

As a backup plan we must create a detailed list, what kind of code constructs not to use if targeting AOT-ed platform, like IOS

My experience so far:

1) Using FirstOrDefault with value types 2) Using Sum(customType =(gt) customType.Property)

Anybody has any idea about how to deal with this?

Regards

g.pickardou
  • 32,346
  • 36
  • 123
  • 268

1 Answers1

4

Suppose you have a well unit tested code.

If you already have unit tests then you're in luck. You simply have to tun those unit tests on an iOS device using Touch.Unit.

As a backup plan we must create a detailed list, what kind of code constructs not to use if targeting AOT-ed platform, like IOS

The closest you'll get is MonoTouch's limitation page. The context, not the API, is often the most important detail.

E.g. generics using value-type will create problems (as it's hard to detect what needs to be generated). People will often hit this when using LINQ, but it's not a LINQ issue - but the types used in the LINQ queries.

1) Using FirstOrDefault with value types

AFAIK that's been fixed in MonoTouch for quite some time (at least several variations of it). OTOH the Unity engine may not have those fixes yet.

2) Using Sum(customType =(gt) customType.Property)

That's a case where not knowing the type(s) makes it impossible to say if it works or not. If/when you get such cases please report them to bugzilla as we'll be able to include them in our test suite (for future releases) and are often able to provide a quick workaround solution to most cases.

poupou
  • 43,413
  • 6
  • 77
  • 174