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]> 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&dat1642
> > _______________________________________________
> > nant-developers mailing list
> > nant-developers@lists.sourceforge.net
> >
> https://lists.sourceforge.net/lists/listinfo/nant-developers
> >
>
>
