Launching an application from an SD card fails. AppDomain.CreateInstanceAndUnwrap() and Assembly.Load() - not implemented?
#21
Posted 15 September 2011 - 12:41 PM
#22
Posted 15 September 2011 - 05:57 PM
#23
Posted 21 September 2011 - 12:39 PM
#24
Posted 22 September 2011 - 06:00 AM
I have just tried this on an N+ I have got a System. NotImplemented Error in mscorlib.dll against AppDomain.CurrentDomain.CreateInstanceAndUnwrapp(.....)
I used MFDeploy and discovered AppDomains set to false. What should I do?
Hi Erich, I reckon you are using the 4.2 RC1 version of the micro framework. Read Chris's answer above that they will most probably fix that in the next release of the framework. Hope that helps
#25
Posted 24 November 2011 - 10:42 PM
Once the official 4.2 PK/SDK come out (very soon), we'll build an RC3 build...and then tweak these settings as appropriate from there.
Hi Chris,
I just started playing with the Netduino Plus and upgraded the firmware to 4.2 RC3. Still having the same AppDomains set to false, is there any plan to fix this any time soon?
Strillo
#26
Posted 17 December 2011 - 07:47 AM
#27
Posted 29 February 2012 - 12:07 AM
Hi Fabien, and all others in the thread
Thanks for the contribution, it could eventually help to a remote update of our software.
Has anyone tested this with the netduino plus?
I am using MF 4.2 RC1 and I am trying your exact code (as all my tries have failed) and I receive the same exception in CreateInstanceAndUnwrap you had.
Cheers
Stavros
Hi All,
I've tried this method on a Netduino plus to dynamicaly load from SD a whole application (24k .pe file) and finaly get it works with the method described above.
But during runtime a finaly have some errors like "Failed allocation for 39 blocks, 468 bytes".
So i've checked memory size and see that my application use 24K more (size of assembly) than when it is deployed directly from VS.
I think the allocation error come from this lack of memory.
So even it is realy far from my understanding , is there any way to have a dynamic assembly load, having the same Memory print than deployed from VS
Regards
#28
Posted 29 February 2012 - 01:50 AM
Hi All,
I've tried this method on a Netduino plus to dynamicaly load from SD a whole application (24k .pe file) and finaly get it works with the method described above.
But during runtime a finaly have some errors like "Failed allocation for 39 blocks, 468 bytes".
So i've checked memory size and see that my application use 24K more (size of assembly) than when it is deployed directly from VS.
I think the allocation error come from this lack of memory.
So even it is realy far from my understanding , is there any way to have a dynamic assembly load, having the same Memory print than deployed from VS
Regards
I briefly toyed around with loading my application from the SD card using this and ran into the same kind of result. For some reason, when loaded dynamically, the memory usage is much higher. Never tried to tracked down why.
#29
Posted 19 March 2012 - 11:12 PM
Am I naive for thinking these functions are almost the polar opposite of basic?
They are basic in the same way that the combination of nand gates to form a latch is fundamental to the design of RAM. AppDomains are fundamental to the .net framework (you can't start a program without one) but they are not basic in the sense of frequent direct use by newbie developers.
#30
Posted 19 March 2012 - 11:22 PM
I briefly toyed around with loading my application from the SD card using this and ran into the same kind of result. For some reason, when loaded dynamically, the memory usage is much higher. Never tried to tracked down why.
I suspect you are creating a new AppDomain rather than loading an assembly into the current AppDomain. If you create a new one, there will be overhead. When memory abounds as on a desktop computer, a couple of K is nothing, but on the N+ it is very significant. The advantage of creating a new AppDomain is that you can unload it, unlike individual assemblies.
On a limited resource device like the N+, the best thing to do is (re)write a config file and reboot, then load whatever your config indicates.
#31
Posted 20 March 2012 - 12:05 AM
I suspect you are creating a new AppDomain rather than loading an assembly into the current AppDomain. If you create a new one, there will be overhead. When memory abounds as on a desktop computer, a couple of K is nothing, but on the N+ it is very significant. The advantage of creating a new AppDomain is that you can unload it, unlike individual assemblies.
On a limited resource device like the N+, the best thing to do is (re)write a config file and reboot, then load whatever your config indicates.
Well, I'm not INTENTIONALLY creating a new appdomain. The code I'm using looks basically like:
string[] files = Directory.GetFiles(@"\SD\assemblies"); const string extension = ".pe"; MethodInfo mainMethod = null; foreach (string file in files) { if (file.LastIndexOf(extension) != file.Length - extension.Length) { continue; } byte[] assemblyData = File.ReadAllBytes(file); Assembly assembly = Assembly.Load(assemblyData); // Search for Main method if (mainMethod == null) { foreach (Type type in assembly.GetTypes()) { MethodInfo m = type.GetMethod("Main", BindingFlags.Public | BindingFlags.Static); if (m != null) { mainMethod = m; break; } } } } if (mainMethod != null) { mainMethod.Invoke(null, new object[0]); }
Basically, I took the .pe files generated by an existing project (that I would otherwise deploy directly from visual studio) and copied them onto my SD card (except the core micro framework ones), and load them up (Assembly.Load). Then search through and locate the "Main" method, once found, I execute it.
I was vaguely concerned with how references (assembly references, not object references) would match up, but I figured I would worry about that when it became a problem.
It does in fact execute my code, but throws memory exceptions before it gets very far. I also tried scoping things such that the assemblyData byte array went out of scope prior to actually executing the method (because that obviously takes up a good chunk of memory), but no luck.
#32
Posted 27 March 2012 - 07:05 PM
Works fine for me, not sure what the difference is between the two processes.
Assembly assm = Assembly.Load(byte[] from FileStream); Type objType = assm.GetType("Namespace.Object"); object obj = (object)objType.GetConstructor(new[] {typeof(object) }).Invoke(new object[0]);
You can pass parameters in the Invoke call if the Constructor needs it.
#33
Posted 28 March 2012 - 08:11 PM
Hi,Instead of CreateInstanceAndUnwrap, I've just been calling the GetConstructor from the Type Object pulled from an Assembly.
Works fine for me, not sure what the difference is between the two processes.
Assembly assm = Assembly.Load(byte[] from FileStream); Type objType = assm.GetType("Namespace.Object"); object obj = (object)objType.GetConstructor(new[] {typeof(object) }).Invoke(new object[0]);
You can pass parameters in the Invoke call if the Constructor needs it.
After testing the both, this Method is simplier and work well but does not produce a real different memory foot print.
#34
Posted 17 April 2012 - 09:07 AM
#35
Posted 20 November 2012 - 10:39 AM
#36
Posted 20 November 2012 - 04:07 PM
Have you played with the Mono Bootloader sample?any suggestion?
http://forums.netdui...nd-sample-apps/
It successfully loads assemblies on the fly and executes them.
Doing so shouldn't corrupt anything.
Chris
- Duefectu likes this
#37
Posted 17 December 2012 - 02:49 AM
#38
Posted 17 December 2012 - 11:45 PM
Are you wanting to attach to a running process? To .PE files which were deployed with the app or ones that are loaded at runtime?Does anyone have a good way to debug or attach the symbols for loaded .pe files and debug them through vs?
Chris
#39
Posted 18 December 2012 - 01:53 PM
Hi Joshua,
Are you wanting to attach to a running process? To .PE files which were deployed with the app or ones that are loaded at runtime?
Chris
I want to debug .PE files that are loaded at run time.
#40
Posted 18 December 2012 - 11:35 PM
Please vote for this issue.I want to debug .PE files that are loaded at run time.
This is a feature which Microsoft is hoping to get into the next version of NETMF. It would be really useful for a number of scenarios; your voice of support is appreciated
Chris
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users