Re: [NAnt-users] Extending asminfo Task (a patch)
- 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=detailaid=1544984group_i
d=31650atid=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
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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
Re: [NAnt-users] Extending asminfo Task
Of course, this would have to be planned for .9 or something as it would be a breaking change for .85. BOb -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: Tuesday, August 22, 2006 2:47 PM 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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users - 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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
Re: [NAnt-users] Extending asminfo Task
Hi James, I would be also interested to use such task, feel free to give it out for testing :). May be I would prefer to be able to use (test) in the way, that does not conflict with current nant installation, if possible. As far as I understand if you will give to the task asm_info name, it will conflict with nants ant_info task, and couldn't be loaded with loadtask. Right? Boni -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Gert Driesen Sent: Dienstag, 22. August 2006 19: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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users - 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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
Re: [NAnt-users] Extending asminfo Task
James Johnston wrote: 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. Do the three code providers generate different C++ output for the same input? I ask because going to the trouble of using the DOM in the first place seems like overkill for the little bit that asminfo needs to know about. It's not as though the syntax of an attribute or import is all that complex. And most projects only really need the version and configuration information, which are the things that change every build. Most other information is better placed in a static file, so that developers can work with it without having to learn NAnt or the build system. The one value I see for having NAnt generate relatively static assembly information is when the same information needs to be shared by multiple languages. If this were driven by text templates instead of a DOM, it wouldn't be as powerful but it would be both simpler and easier to extend to languages that don't have a DOM at all. We used to just do this manually, writing text to a file from the NAnt script. My many reason for changing it is that it makes the NAnt build file cleaner, not that it gave us anything that couldn't be done relatively easy some other way. Of course, what's done is done and I wouldn't expect it to change. But my original question remains: If the C++ providers are going to generate the same syntax, then does it matter which one gets used? Gary 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. Best regards, James Johnston - 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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users - 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=lnkkid=120709bid=263057dat=121642 ___ NAnt-users mailing list NAnt-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-users
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=detailaid=1544984group_i
d=31650atid=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
