----- Original Message ----- 
From: "James Johnston" <[EMAIL PROTECTED]>
To: <nant-users@lists.sourceforge.net>
Sent: Wednesday, August 23, 2006 2:42 AM
Subject: Re: [NAnt-users] Extending asminfo Task (a patch)


>I decided the best way to fix this was to fix the Language property of
> AssemblyInfoTask so it is a string instead of an enumeration.
>
> I did not add support for named attribute arguments as I don't need that
> in my application; however it does sound like a good addition to make...
>
> I submitted a patch; you can find it at
> http://sourceforge.net/tracker/index.php?func=detail&aid=1544984&group_i
> d=31650&atid=402870
>
> Some things about the patch:
>
> * It was made against released v0.85 RC4 of NAnt since that is what I
> have been using and also I am not terribly familiar with CVS and it was
> easier to download the ZIP file from the NAnt home page.
>
> * It is very easy to test or use the patch without rebuilding the
> entire Nant.DotNetTasks assembly and modifying your v0.85 RC4
> installation.  Just run the patch against the v0.85 RC4 source.  Then
> copy the resulting file someplace and rename it.  You'll need to change
> the name of the class and task so that it does not conflict with the
> existing task (e.g. rename AssemblyInfoTask to MyAssemblyInfoTask).  You
> can then build it in NAnt as follows:
>
> <csc output="C:\tmp.dll" target="library" rebuild="true"
> verbose="false" debug="Full">
> <sources>
> <include
> name="C:\Code\060822-ACLEdit\SolutionFiles\VAssemblyInfoTask.cs" />
> </sources>
> <!-- You must extract the resources from
> NAnt.DotNetTasks.dll.  Lutz Roeder's Reflector is a good tool for this.
> -->
> <resources>
> <include
> name="C:\tmp.Resources.Strings.resources" />
> </resources>
> <references>
> <include
> name="${path::combine(nant::get-base-directory(), 'NAnt.Core.dll')}" />
> <include
> name="${path::combine(nant::get-base-directory(),
> 'NAnt.DotNetTasks.dll')}" />
> </references>
> </csc>
>
> After that you can use <loadtasks> to load the compiled DLL and then
> refer to your new task.  It is used same as usual, except now you can
> specify a lot more languages for "language" attribute, including the
> fully-qualified type name and assembly of any code DOM - just as with
> the script task.  The only breaking compatibility thing was the behavior
> of the "asis" attribute, as described in next point.
>
> * No longer are the "imports" added to the top of the code file.
> Instead, a fully-qualified type name is emitted instead.  The original
> code seemed to be working around a bug in C# where "using" would be
> placed *after* the attributes, causing a compile error.  The work around
> was to emit two different code structures into the same output stream.
> I did not think it realistic to make such special cases like this,
> especially if other code DOMs have the same problem, or if the code DOM
> might output code that fails to compile when two emits are sent to the
> same stream, etc., so I fixed it so that the full type name is emitted
> as part of the attribute.  The side-effect here is that if you use the
> "asis" attribute == true it does not discover a fully-qualified type
> name and so you have to fully-qualify it instead.

I'll need to look into this before I can comment on it.

> * The code to load the appropriate code DOM from a string was found in
> <script> task, as Gert suggested.  That code was the CreateCodeGenerator
> and CreateCodeDOMProvider methods.  However, they were private and not
> accessible.  In the interests of keeping all changes in a single file so
> that it could be easily tested against any NAnt 0.85 RC4 as described
> above, I copied the code into AssemblyInfoTask.cs.  Of course that is
> not ideal, it really should be moved out of both tasks into some common
> "LanguageRecognizer" type class/routine since it is really not something
> that should be specific to a task.  The one modification I made to look
> out for when comparing the two copies of the method was to modify the
> list of "magic" language strings (e.g. "C#", "VB", etc.).  I added
> "CSharp" to the list so that compatibility with existing scripts using
> the enumeration is maintained.  ("CSHARP" was already in the list but
> the list is case-sensitive).
>
> * Resource strings NA2007/2008 can likely be removed from the resource
> file if they are not used anywhere else; this removal was not put in the
> patch.  (These were error messages saying such things as this and that
> language is not supported, etc.).
>
> I'm hoping this improvement will be able to be merged with the NAnt
> source code repository - let me know if there's anything that should be
> done for this to happen because I don't like being restricted to VB/C#
> for this task out of the released v0.85 RC4 binaries.  (FYI this is the
> first real submission I've made to an open source project, so I'm kinda
> new to the process).

I'll look into your submission ASAP (but probably won't have time in the 
next few days).

Your contribution will definitely make it into the NAnt repository (but 
perhaps in a modified form).

However, our priority right now is to get NAnt 0.85 released so I'll 
probably hold off committing your changes until after that release.

I hope you understand,

Gert


-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
NAnt-users mailing list
NAnt-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-users

Reply via email to