The existing scripting system is c#/codedom and uses reflection to find attributes on classes and methods in the assembly compiled and loaded at runtime. After finding out about clrtype.py I thought the IronPython implementation could be very easy without changing much of the existing code, until I tried reloading the script.
I did have some luck getting the script to reload by changing the get_clr_type_name def in clrtype.py to add a unique string to the end of the name. I haven't spent a lot of time testing that to fully understand the ramifications though. I don't think I really care what the clrtype name is, as long as I can get an instance of it. And if its different every time, that eliminates the duplicate type name exception. I guess ideally it would only generate the unique string when the script is reloaded, but right now it generates a new one every time the function it is called. I'm sure that can't be good... need to find a way around that. Which set of DLR APIs can you use to query the objects? I know about the python inspect module, is there something similar in the DLR api? Thanks, Jared On Wed, Oct 31, 2012 at 11:53 AM, Jeff Hardy <jdha...@gmail.com> wrote: > On Tue, Oct 30, 2012 at 8:13 PM, Jared Whitby <jwhi...@gmail.com> wrote: >> Hey guys, >> >> I've been trying to use IronPython as a scripting solution in a project I am >> working on. I am using clrtype.py from the clrtype sample to expose >> attributes on methods into c# so I can use reflection to register them with >> my application. The first time the script runs, everything works fine. But I >> want the users to be able to change the script while the application is >> running so I need to load and run the script again. When I try to load and >> run the script a second time I get a ArgumentException “Duplicate type name >> within an assembly”. >> >> ... >> >> Any ideas how to get around this? Am I doing something wrong that you can >> see? > > It's a limitation of how IronPython generates code (and by extension, > clrtype.py). When it runs, it creates a dynamic assembly and creates > types in it, but it only does this once per process. Your use case is > interesting, and one that I don't think was ever considered - it was > assumed that the scripts (using clrtypes) would not be reloaded. One > potential issue is that I believe dynamic assemblies cannot be garbage > collected, although this may have changed in newer version of the CLR > (I can't keep track anymore!). > > Would it be possible to not use reflection? Or does your system > require it for other reasons? You could potentially use the DLR APIs > to query the objects and then register them, which would avoid the use > of clrtypes at all. > > - Jeff _______________________________________________ Ironpython-users mailing list Ironpython-users@python.org http://mail.python.org/mailman/listinfo/ironpython-users
