Hi Christian, I've fixed the dynamic assembly issue locally, and commit it to cvs in a few minutes.
I'll let you know when I've finished uploading a new nightly build for you to test. Gert > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On > Behalf Of Christian Birkl > Sent: donderdag 16 maart 2006 20:03 > To: Michael O'Brien > Cc: nant-developers@lists.sourceforge.net > Subject: Re: [nant-dev] Custom tasks from XML / using dynamic > assemblies > > Oh i think i forgot to mention you'll propably need the > latest nightly-build since there's a new public TaskBuilder() > constructor overload which isn't (?). > > Also forgot three other changes, remove the variable > "dynAssemblyFileName" and change your calls of > DefineDynamicModule and DefineDynamicAssembly w/o the use of > a filename. The last one is to change the > AssemblyBuilderAccess enum from "RunAndSave" to just "Run". > > > 2006/3/16, Michael O'Brien <[EMAIL PROTECTED]>: > > Hi Christian, > > hooking ProcessExit doesn't seem to work, I think > because this occurs > before the AppDomains are unloaded? Not sure about this > but Chris > Brumme has a post at > > http://blogs.msdn.com/cbrumme/archive/2003/08/20/51504.aspx which > seems to imply this, if I've read it correctly. In any > case, the event > is fired, but the file isn't deleted because there is > an open lock on > it. > > There is another old trick used when you want to load > an assembly > without locking its file, which is to load its contents > into a byte > array, then call Assembly.Load(byte[]). The loaded > assembly then takes > its location from the currently executing assembly (or > possibly the > primary assembly). Unfortunately NAnt.Core.TaskBuilder > is tied quite > closely to the assembly's file name, and this doesn't > work. Maybe > refactoring this class to include a TaskBuilder(Type t) > constructor > could help here? I'm more than happy to give this a try > if it sounds > like a good idea. > > If you want to have a try yourself, the code is at > http://mcobrien.org/files/NantXmlTasks.zip. The code is > a bit rough at > the moment, but CustomTaskBuilderTask does the > Reflection.Emit work, > and BaseCustomTask simplifies everything by containing > most of the > code the custom tasks use. > > cheers > Michael > > On 14/03/06, Christian Birkl < > [EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]> > wrote: > > > > > > > > Hi Michael, > > > > Why not just hook to ProcessExit Event of the current > AppDomain? > > > > AppDomain.CurrentDomain.ProcessExit += new > > EventHandler(CurrentDomain_ProcessExit); > > > > private void CurrentDomain_ProcessExit(object sender, > > EventArgs e) { > > foreach (string myDynAssFile in DynAssFiles) > > System.IO.File.Delete (myDynAssFile); > > } > > > > Or depending on your type of generation method don't > use any file based > > dynamic assemblies, as far as i remember it is > possible to generate "In > > Memory" Assemblies (TypeBuilder, MethodBuilder, ...) > w/o the need to store > > your assembly to disk. > > > > Anyway, cool idea :-) Indeed a nice to have feature > which would nicely fit > > into NAntContrib or better NAnt ;-) > > > > Christian > > > > 2006/3/14, Michael O'Brien < [EMAIL PROTECTED]>: > > > > > Hi everyone, > > > > > > I'm new on this list, so I hope this it's the right > place to discuss > > > this, but I've written a custom task that allows > buildfile authors to > > > define new tasks using XML (see below for details). > It works well, but > > > I have one problem: I generate a dynamic assembly > when it executes > > > which it seems has to be persisted to disk (mainly because > > > TypeFactory.ScanTypeForTasks calls the Location > property on my dynamic > > > assembly). As such, the assembly is left over on > disk when the script > > > finishes executing, which is pretty ugly. > > > > > > Does anyone know if there is any way to avoid this, > either by managing > > > to add a task from my dynamic assembly, or ensuring > the assembly is > > > deleted when the script finishes? > > > > > > For the interested, my task works as in the > following example -- the > > > <customTask> element defines a new task that > accepts a list of > > > parameters, which are passed to the rest of the > <customTask> block > > > when the <logMessage> element appears. We're using > it quite a bit in > > > some complex scripts we have to refactor otherwise > complex targets. If > > > you'd like the C# source to this, just ask and I'll > put it on a > > > server. > > > > > > thanks > > > Michael > > > > > > -- example follows: > > > <customTask name="logMessage"> > > > <parameters> > > > <parameter parameterName="msg" required="true" /> > > > </parameters> > > > > > > <echo message="${msg}"/> > > > </customTask> > > > > > > <logMessage msg="hi there" /> <!-- prints hi there > to the console --> > > > > > > > > > ------------------------------------------------------- > > > This SF.Net email is sponsored by xPML, a > groundbreaking scripting > > language > > > that extends applications into web and mobile > media. Attend the live > > webcast > > > and join the prime developer group breaking into > this new coding > > territory! > > > > > > http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720&dat1 642 <http://sel.as-us.falkag.net/sel?cmdlnk&kid0944&bid$1720> &dat1642> > > > _______________________________________________ > > > nant-developers mailing list > > > nant-developers@lists.sourceforge.net > <mailto:nant-developers@lists.sourceforge.net> > > > > > https://lists.sourceforge.net/lists/listinfo/nant-developers > > > > > > > > > > > ------------------------------------------------------- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnk&kid0944&bid$1720&dat1642 _______________________________________________ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
