Re: [Pnet-developers] Re: [Bug #2948] Loading assemblies from memory

[Gopal V]

If memory serves me right, Chris Smith wrote:
> it then does a spot of reflection, and invokes the webservice 'method'.  Once 
> the wbeservice has 'run' and returned back to DGEEInvoke, its results are 
> serialized and returned. DGEEInvoke now finishes.

Hmm... there you touch a weak spot ... you'll have to devise some new 
internal call to load stuff from memory .. Reflection API and Assembly.Load
assume a filename . 

I think much better performance can be achieved by Caching the ILImage*
generated during loading from disk...

To be accurate , keep the ILImage* for each .dll in a table of sorts ?.

"webservice.dll" => ILImage* // null if not yet loaded ...

probably use an LRU Cache ... etc...

Also the DGEEWSInvoke.DGEE_run() could be made to accept the ILImage*
stuff wrapped in a Reflection.Assembly instead of the String filename...

Having said that , it might become a potential security risk as with
any buffer of executable in memory.

> (which can be loaded off disc as it will always be available locally - 
> memload will be preferred for speed though) before doing an ILExecThreadCall 
> on the thread containing the DGEEInvoke bootstrap?

Memory load will be really useful only if you're loading the class from
the network or similar source. Java allowed that with custom class loaders.

If you had to load stuff off a network source or other remote repository 
memload would be very useful. But as of now , I think caching ILImage * 
makes more sense.

Gopal
-- 
The difference between insanity and genius is measured by success