OTA and lack of memory

[smersh1307n2]

When I implemented OTA through reflection, I noticed a strong decrease in free memory.
Measured using the nanoFramework.Runtime function.Native.GC.Run.
It turns out to be very unprofitable to use such a method of updating the executable algorithm via wifi or bluetooth.
If the "TW" assembly is deployed as usual, then loaded and started, the amount of free memory will be 28104 bytes.
If the "TW" assembly is loaded and run from flash memory, then only 7800 bytes of free memory remain.
Maybe I'm doing something wrong?

byte[] b = GetFile("I:\PW.pe");
System.Threading.Thread.Sleep(40);
var epAsm = System.Reflection.Assembly.Load(b);
var name = epAsm.GetName();
var typet = epAsm.GetType(name.Name + ".Core");
var cnstr = typet.GetConstructors();
_MCore.ExecutingProgram = (Main.IProgram)cnstr[0].Invoke(new object[] { });

19924 bytes on falsh memory.
Assembly: TW (1.0.0.0) (1792 RAM - 22196 ROM - 7070 METADATA)

AssemblyRef = 44 bytes ( 11 elements)
TypeRef = 244 bytes ( 61 elements)
FieldRef = 0 bytes ( 0 elements)
MethodRef = 344 bytes ( 86 elements)
TypeDef = 272 bytes ( 34 elements)
FieldDef = 268 bytes ( 133 elements)
MethodDef = 320 bytes ( 160 elements)
StaticFields = 0 bytes ( 0 elements)

Attributes = 312 bytes ( 39 elements)
TypeSpec = 0 bytes ( 0 elements)
Resources = 0 bytes ( 0 elements)
Resources Files = 0 bytes ( 0 elements)
Resources Data = 0 bytes
Strings = 3939 bytes
Signatures = 1010 bytes
ByteCode = 11059 bytes

I do not know the mechanism of application deployment. Do I understand correctly that all the pe files of the project are completely on the flash memory in the blob? Maybe it is possible to additionally check for the presence of a file in flash memory, for example, "I:\exprogram.run", when starting the device?
"exprogram.run" contains a link to another file in which pe are written one after another in the order required for loading. Then load them after the main deployed pe files at the nanoclr level?

[josesimoes]

I don't think you're doing anything wrong. Loading an assembly in RAM in order to load it through reflection will necessarily have impact on the available RAM. Note that this IFU demonstrated on the sample is not ideal, rather a workaround available until the "full" feature becomes available.

[smersh1307n2]

Thank you. It's a pity that at the moment there are no other options. I think the possibility of working with full functionality would open up excellent prospects.

[josesimoes]

Agreed! I'm looking forward for us to resume work on that.
Currently we're lacking funding and developer hours to tackle this.

[jingqunhu]

I ran into the same problem and I took a larger memory module to solve it.