Try putting this in your code and calling it from FinishedLaunching
private void MonoTouchForcedCompilationHacks()
{
{
var hack1 = new IFooSession[0];
if(!((ICollection<
IFooSession>)hack1).Co
Thanks, this confirms my vague sense that the problem came from something
the LINQ depends on that is not generated during compilation. This specific
fix doesn't work, since the type involved isn't quite the same. I'm
relatively new to the guts of LINQ, so I think I need some help parsing
exactly w
Hi Brian,
Can you submit a bug report to http://bugzilla.xamarin.com? This is
something the JIT guys will have to take a look at because I don't know
enough to answer this question.
Thanks,
Jeff
On Fri, Sep 9, 2011 at 10:41 AM, Brian Schuth wrote:
> I have simplified this even further; with
I have simplified this even further; with all the interface cruft out
of the way, it seems like the problem is that even the simplest "join"
is going to cause a JIT error? This sounds like a bug to me, but I'm
happy to be told it's my fault :).
The code that causes the problem is below, reduced to
A couple of months back I hit JIT errors when using LINQ for objects. I was
never able to resolve them, but as the LINQ involved was pretty simple, I
just "unrolled" it into procedural code.
Now I'm getting more of them, and I'd really prefer to leave the LINQ alone
if possible. The exception I'm
(Resending, with git link instead of the source I attached, put me over the
40k limit...)
A couple of months back I hit JIT errors when using LINQ for objects. I was
never able to resolve them, but as the LINQ involved was pretty simple, I
just "unrolled" it into procedural code.
Now I'm getting
