[Ironpython-users] clrtype.py duplicate type name within an assembly

Jared Whitby jwhitby at gmail.com
Thu Nov 1 02:09:29 CET 2012

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?


On Wed, Oct 31, 2012 at 11:53 AM, Jeff Hardy <jdhardy at gmail.com> wrote:
> On Tue, Oct 30, 2012 at 8:13 PM, Jared Whitby <jwhitby at 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

More information about the Ironpython-users mailing list