[sdk] Enable the SRE runtime code inside iOS builds #16151
Conversation
This will allow the interpreter to use System.Reflection.Emit. Note: There is a small size increase (about 50kb) for an application built in release mode with the LLVM backend (even if the interpreter is now used).
This will allow the interpreter to use System.Reflection.Emit. Note: There is a small size increase (about 50kb) for an application built in release mode with the LLVM backend (even if the interpreter is now used). Backport of mono#16151
This will allow the interpreter to use System.Reflection.Emit. Note: There is a small size increase (about 50kb) for an application built in release mode with the LLVM backend (even if the interpreter is now used). Backport of mono#16151
| --enable-icall-export \ | ||
| --enable-maintainer-mode \ | ||
| --enable-minimal=ssa,com,interpreter,jit,reflection_emit_save,reflection_emit,portability,assembly_remapping,attach,verifier,full_messages,appdomains,security,sgen_remset,sgen_marksweep_par,sgen_marksweep_fixed,sgen_marksweep_fixed_par,sgen_copying,logging,remoting,shared_perfcounters,gac \ | ||
| --enable-minimal=ssa,com,interpreter,jit,portability,assembly_remapping,attach,verifier,full_messages,appdomains,security,sgen_remset,sgen_marksweep_par,sgen_marksweep_fixed,sgen_marksweep_fixed_par,sgen_copying,logging,remoting,shared_perfcounters,gac \ |
There was a problem hiding this comment.
reflection_emit_save should still be disabled imho.
There was a problem hiding this comment.
the old preview (and sample code) supported it
There was a problem hiding this comment.
How was it supported if it was disabled before ? Also, what is the use case for supporting sre save on ios ?
There was a problem hiding this comment.
We had a preview last fall for the interpreter which had SRE (including saving) enabled. Our sample shows this worked.
The main use case is compatibility with netstandard code that is not aware that SRE could work without saving.
There was a problem hiding this comment.
Wouldn't be better to just map AssemblyBuilder.Save to AssemblyBuilder.Run in that case ?
There was a problem hiding this comment.
Better ? no. Less worse ? maybe :)
We're doing this (interpreter, SRE...) to increase compatibility between .net runtimes. Why go half way and impose a different set of limitations ?
Can you explain the problem(s) where remove this sre-save would solve ?
There was a problem hiding this comment.
Well, sre.save is for saving assemblies to disk, i.e. AssemblyBuilder.Save (filename), but afaik ios has no file system, so this functionality won't work.
There was a problem hiding this comment.
Well, sre.save is for saving assemblies to disk, i.e. AssemblyBuilder.Save (filename),
yup, exactly
but afaik ios has no file system, so this functionality won't work.
hmm.. wrong. iOS has a file system and, like I said above, that's a feature that worked in the old preview.
You might be confusing that you can't write executable code (well you can but it cwon't execute). However since it's interpreted that restriction does not exists - it's simply data like any text/binary file an app would write to / read from.
This will allow the interpreter to use System.Reflection.Emit. Note: There is a small size increase (about 50kb) for an application built in release mode with the LLVM backend (even if the interpreter is now used). Backport of #16151
This will allow the interpreter to use System.Reflection.Emit. Note: There is a small size increase (about 50kb) for an application built in release mode with the LLVM backend (even if the interpreter is now used). Backport of #16151
[sdk] Enable the SRE runtime code inside iOS builds Commit migrated from mono/mono@5bc4944
This will allow the interpreter to use System.Reflection.Emit.
Note: There is a small size increase (about 50kb) for an application
built in release mode with the LLVM backend (even if the interpreter
is now used).