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. * 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). Best regards, James Johnston -----Original Message----- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Tuesday, August 22, 2006 18:47 To: James Johnston; nant-users@lists.sourceforge.net Subject: RE: [NAnt-users] Extending asminfo Task > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:nant-users- > [EMAIL PROTECTED] On Behalf Of James Johnston > Sent: dinsdag 22 augustus 2006 20:07 > To: nant-users@lists.sourceforge.net > Subject: [NAnt-users] Extending asminfo Task > > It seems that the AssemblyInfoTask (asminfo) is very inflexible in > that you are fixed to using the VB/C# code DOMs. I would like to use > it with the new CppCodeProvider in .NET 2.0 for generating C++ code, > and I'm sure there are other code generators out there that people > would also like to use. > > Has any work been done to add this sort of feature to AssemblyInfoTask? > The current "Language" property is a simple enumeration. I'm thinking > that in addition to that property, there should be a "CodeProviderType" > property that contains the full type name so one can use any arbitrary > code generator. E.g. one could set it to > "Microsoft.VisualC.CppCodeProvider, CppCodeProvider, Version=8.0.0.0, > Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". I think the answer > is not to simply add "C++" to the CodeLanguage enumeration, because > there are three different C++ code generators: MCppCodeProvider (for > v1.1), CppCodeProvider (for v2.0), and CppCodeProvider7 (also comes > with > VC++ 8.0). And there are likely code DOMs for other languages too. > > If there is interest for this enhancement, I would just as soon make > the changes myself and submit a changeset - I don't think it would be > very hard to add a feature like this. Sure, there's interest for this. I wouldn't add a new attribute though. Let's just change the existing Language property (language attribute) to take a string. Have a look at the <script> task as we do exactly the same there. The <asminfo> task should probably also support setting named attribute arguments (using a nested <argument> type). 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
