Quote:Original post by Umbrae
Quote:Original post by Structural
I was wondering how you used the shadowcopying..
I didn't get far enough to use it, so I guess I would be in the same boat as you.
If you do find out (and likewise if I find out) let everyone know, I'm sure it's useful information.
I found a hint:
scriptAppDomain.Load() will indeed force the assembly to be loaded in the current appdomain.You could create a shared "ScriptEngine" assembly, and invoke Assembly.Load() through a remote call on the script appDomain. The script engine assembly will be locked, but that won't be an issue as the actual script will be in yet another assembly.
I think you could use
Assembly.ReflectionOnlyLoad() to get reflection info hopefully without locking the assembly.
One thing that is still a blank more or less is how easy it'll be to invoke methods and getting members with only having reflection info.
So, to recap how to get around the locking of the assembly:
- create "Script Engine" assembly
- create script appDomain
- load script engine assembly in script's appdomain
- invoke a method in your script engine assembly and in the script appDomain to load your actual script assembly
- use Assembly.ReflectionOnlyLoad() to get reflection info of the script assembly (UNCERTAIN if this leaves the assembly file unlocked, MSDN doesn't state)
- somehow invoke methods and get members in the script appDomain
I'm going to try out the last two items. If that works I believe all bases are covered for using C# as a scripting language (the way I (think I) want it to work at least).
[edit]
Assembly.ReflectionOnlyLoad() DOES lock the file... buggery! A quick google seems to indicate there is no way around it.
This also means that anything you try to reflect the object will result in an attempt to load the assembly (reflection only or not) in the main appDomain. Even myScriptObject.GetType() from the main appDomain will.
One way to get around this may be to give the script engine an interface to invoke methods and get/set member variables and serialize/deserialze objects. But I don't feel it is viable to build all that for my personal project.
And another thing just hit me... even IF I can invoke script from the game, I still haven't figured out how to invoke game methods from script.
This poses an entirely new problem I think.
Right... I'm going to put this to rest now. This whole appDomain boundary stuff is giving me a headache.
If you figure it out Umbrae then let me know. I'm still hoping it is possible.
[/edit]
[Edited by - Structural on May 28, 2008 12:36:50 PM]