The new patch looks good.<br><br><br><div class="gmail_quote">On Thu, Nov 5, 2009 at 6:30 PM, Sebastien Pouliot <span dir="ltr">&lt;<a href="mailto:sebastien@ximian.com">sebastien@ximian.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Wed, 2009-11-04 at 16:31 -0200, Rodrigo Kumpera wrote:<br>
&gt; The icall removal patch is ok.<br>
<br>
</div>committed<br>
<div class="im"><br>
&gt; The second one is tricky. Do we really want to completely disable COM<br>
&gt; support when running under the sandbox?<br>
<br>
</div>I don&#39;t see this as an immediate issue but...<br>
<div class="im"><br>
&gt; It does make sense for moonlight, but not for other users of coreclr.<br>
&gt;<br>
&gt; I believe we should only fail COM for non-platform assemblies which<br>
&gt; has the same result for moonlight<br>
<br>
</div>a new patch is attached.<br>
<div class="im"><br>
&gt; but won&#39;t<br>
&gt; bite future users of the sandbox code.<br>
<br>
</div>Well it won&#39;t change anything for Moonlight[1] but it will still bite<br>
any other (well future) user of coreclr unless the BCL they provide<br>
offers the required COM types [2]. Otherwise it will simply abort (like<br>
id does today).<br>
<br>
Sebastien<br>
<br>
[1] unless someone adds a [ComImport] somewhere in the platform code -<br>
but that would not pass our test suite :)<br>
<br>
[2] A added a FIXME in the patch about this. In any case the g_abort<br>
should make it clear enough to runtime embedders<br>
<div><div></div><div class="h5"><br>
&gt;<br>
&gt;<br>
&gt; On Thu, Oct 29, 2009 at 4:43 PM, Sebastien Pouliot<br>
&gt; &lt;<a href="mailto:sebastien@ximian.com">sebastien@ximian.com</a>&gt; wrote:<br>
&gt;         Hello,<br>
&gt;<br>
&gt;         Two small/easy patches for review.<br>
&gt;<br>
&gt;         The first one avoid calling mono_com_init when coreclr is<br>
&gt;         enabled*.<br>
&gt;         This avoid a crash if some assembly use [ComImport] on a type<br>
&gt;         and throw<br>
&gt;         a TypeLoadException - which is what happens in Silverlight.<br>
&gt;<br>
&gt;                * For some reason (I guess it use COM for it&#39;s platform<br>
&gt;         code,<br>
&gt;                while Moonlight does not) Silverlight expose<br>
&gt;         [ComImport] but<br>
&gt;                otherwise does not support COM (as least for<br>
&gt;         application code).<br>
&gt;<br>
&gt;         Second patch removes some internal calls (all strings except<br>
&gt;         one) that<br>
&gt;         are not used (anymore) in the class libraries.<br>
&gt;<br>
&gt;         Sebastien<br>
&gt;<br>
&gt;         p.s. both patches were created from 2-6 branch but I&#39;ll commit<br>
&gt;         them<br>
&gt;         against HEAD too.<br>
&gt;<br>
&gt;         _______________________________________________<br>
&gt;         Mono-devel-list mailing list<br>
&gt;         <a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
&gt;         <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
&gt;<br>
&gt;<br>
&gt; _______________________________________________<br>
&gt; Mono-devel-list mailing list<br>
&gt; <a href="mailto:Mono-devel-list@lists.ximian.com">Mono-devel-list@lists.ximian.com</a><br>
&gt; <a href="http://lists.ximian.com/mailman/listinfo/mono-devel-list" target="_blank">http://lists.ximian.com/mailman/listinfo/mono-devel-list</a><br>
</div></div></blockquote></div><br>