The [MTAThread] on Main puts your executable's starting thread into the MTA, yes. But if you're using ir.exe, the starting thread will be in the STA. I'm not on a computer where it's easy for me to check if "require 'mscorlib'" ends up triggering AssemblyResolve, but it shouldn't if you use the full strong name.
From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-boun...@rubyforge.org] On Behalf Of Orion Edwards Sent: Wednesday, August 12, 2009 8:54 PM To: ironruby-core@rubyforge.org Subject: Re: [Ironruby-core] COM security question I don't think I need to be in the MTA apartment (The virtual server docs say that performance is much improved in MTAThread but should work in STA), but shouldn't the [MTAThread] on Main() be enough? I'll try explictly loading the dll and see if that works when I next get time... Question about that though - in order to do any of this, I need require 'mscorlib' Will that call AssemblyResolve anywhere along the way itself? On Thu, Aug 13, 2009 at 3:29 PM, Curt Hagenlocher <cu...@microsoft.com<mailto:cu...@microsoft.com>> wrote: Ah, I'm an idiot. CoInitializeSecurity is per-process, not per thread. I think this problem is related to the one described at http://lists.ironpython.com/pipermail/users-ironpython.com/2008-April/006941.html. If that's so, it suggests that loading the assembly manually with Assembly.Load instead of "require" - being sure to do whatever it takes to avoid triggering the AssemblyResolve event - might fix the problem. Do you need to be in the MTA apartment? If so, you'd also need to create a new MTA thread or you'd need to start ir.exe with "-X:MTA".
_______________________________________________ Ironruby-core mailing list Ironruby-core@rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
