Doug wrote: > On Tue, Jan 11, 2011 at 8:13 AM, Doug Blank <doug.bl...@gmail.com> > wrote: > > Two questions about referenced assemblies (which are really perhaps > > DLR questions): > > > > 1) I'd like to be able to use different names than are used in a DLL. > > For example, say I have a Library.dll, and it has a class > > "ReallyBadName". Is there an easy way that I can rename or alias > > ReallyBadName after I add a reference to Library? I'd like this to > > work for all of my DLR languages, so I'd like to do it right after I > > add the reference, rather than, say, doing it in Python with "import > > ReallyBadName as GoodName"---but that is the effect I want. > > Ok, maybe if I ask this a slightly different way: when IronPython says "import > ReallyBadName" where does that name need to match in order to import? I > presume that I could change it somewhere in clr.References, and could > import the objects via another name. Would that work?
ReallyBadName needs to match a namespace name or a top-level class name (a class w/ no namespace). Unfortunately there's no way to publish this under a different name. The best thing I can think of would be if you had a .py file like: BetterNames.py: import ReallyBadName as GoodName then you could do: from BetterNames import * Another possibility which might work but is a little crazy would be to implement your own Assembly object and do a clr.AddReference(yourAssembly). You'll then need to override things like GetTypes() / GetExportedTypes() and then you'd also need to subclass Type to return a different name. And that's where things will start getting difficult because now we don't have a real type object to create instances from. It might be possible to override enough of the mebers that it'll work but I wouldn't be surprised if it wasn't possible. > > I'm trying to make generic DLLs that could be loaded directly from the DLR > languages, and would be appropriate for the IP users. > > > 2) Is there a way that I could have a Library.dll bring in other > > assemblies so that they would be available to DLR languages? Of > > course, one could load an assembly in an assembly that you > > clr.AddReference, but that wouldn't make it available to all of the > > DLR languages right? It seems that one would need a callback where the > > clr was passed into the assembly which was clr.AddReference-ed, so > > that it could add references too. Could I overload the clr importer to > > do that? Or is there a better way? > > Likewise, I'd like so that when I "import Library" (where Library is a DLL), > it will > include other DLLs to be available for DLR language access. To load the additional assemblies ultimately you'll need a ScriptRuntime/ScriptDomainManager to add the assemblies to. Unfortunately how you get ahold of those is dependent upon the language. For IronPython you can have a method which takes a CodeContext object as the 1st param and it'll let you get back to the SDM - but the user will need to call that method at some point. Another possibility would be implementing a built-in module which is IronPython specific. That'll give you a PerformModuleReload method which is called to initialize the module and that can load additional assemblies. And you could then expose the types under different names as well. But it's again completely IronPython specific. > > -Doug > > > Thanks for any pointers, > > > > -Doug _______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
