Re: [NAnt-users] Extending asminfo Task (a patch)

[James J. <jjo...@vi...>]

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=3Ddetail&aid=3D1544984&grou=
p_i
d=3D31650&atid=3D402870

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=3D"C:\tmp.dll" target=3D"library" rebuild=3D"true"
verbose=3D"false" debug=3D"Full">
			<sources>
				<include
name=3D"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=3D"C:\tmp.Resources.Strings.resources" />
			</resources>
			<references>
				<include
name=3D"${path::combine(nant::get-base-directory(), 'NAnt.Core.dll')}" =
/>
				<include
name=3D"${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 =3D=3D 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:ger...@te...]=20
Sent: Tuesday, August 22, 2006 18:47
To: James Johnston; nan...@li...
Subject: RE: [NAnt-users] Extending asminfo Task

> -----Original Message-----
> From: nan...@li... [mailto:nant-users-=20
> bo...@li...] On Behalf Of James Johnston
> Sent: dinsdag 22 augustus 2006 20:07
> To: nan...@li...
> Subject: [NAnt-users] Extending asminfo Task
>=20
> It seems that the AssemblyInfoTask (asminfo) is very inflexible in=20
> that you are fixed to using the VB/C# code DOMs.  I would like to use=20
> it with the new CppCodeProvider in .NET 2.0 for generating C++ code,=20
> and I'm sure there are other code generators out there that people=20
> would also like to use.
>=20
> 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=20
> "Microsoft.VisualC.CppCodeProvider, CppCodeProvider, =
Version=3D8.0.0.0,=20
> Culture=3Dneutral, PublicKeyToken=3Db03f5f7f11d50a3a".  I think the =
answer

> is not to simply add "C++" to the CodeLanguage enumeration, because=20
> there are three different C++ code generators:  MCppCodeProvider (for=20
> v1.1), CppCodeProvider (for v2.0), and CppCodeProvider7 (also comes=20
> with
> VC++ 8.0).  And there are likely code DOMs for other languages too.
>=20
> If there is interest for this enhancement, I would just as soon make=20
> the changes myself and submit a changeset - I don't think it would be=20
> 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