The <script> is currently not support on Mono. The reason for this is that the <script> task supports C#, VB.NET and JScript.NET, and Mono is still lacking support for JScript.NET (at least in officially released versions).I wonder if we can get this working by loading the language providers via reflection. It would be a shame to do without the script task because of the lack of JScript which probably isn't even used that much for nant build scripts.
Yeah, we should probably also support third-party code generators/providers. Should we have a nested <generator> element, which has two attributes : assembly and provider (or so) :
That's a good idea, currently scripts in other languages require a custom task to be written by a third party, a la the <boo> element.
<script>
<generator assembly="NemerleCodeProvider.dll" provider="Nemerle.Contrib.NemerleCodeProvider" />
<code>
.....
</code>
</script>
(assembly could be optional)
or should we just allow users to specify a fully qualified name for a class implementing System.CodeDom.Compiler.CodeDomProvider in the language attribute ?
In that case, the assembly containing the codeprovider should be in the GAC, but I don't think that's really an issue ...
Why not make the 'language' attribute of the script element optional, and add optional 'provider' and 'providerassembly' attributes? Kind of a combination of the above two approaches.
Then all three variants use a consistent syntax:
<script language="C#">
Built-in language (aka NAnt knows the provider for C#)
<script provider="Nemerle.Contrib.NemerleCodeProvider">
Third-party language, assembly containing code provider is in the GAC
<script provider="Foo.Bah.ExampleCodeProvider" providerassembly="/foo/bah.dll">
Third-party language, assembly containing code provider is in the specified assembly.
Is there a fourth option, where the assemblies required for the code provider are spread across multiple assemblies?
<script provider="Complex.Code.Provider">
<providerassemblies>
<fileset basedir="${code.provider.bin}">
<include name="*.dll" />
</fileset>
</providerassemblies>
...
Note that this last case caters for more than just 'all assemblies in a folder'.
surely a shortcut
nant:get-version() function would be better than having to do: assembly::get-version(nant::get-location())
Not sure about this, it is indeed shorter, but we can't provide shortcuts for all functions ...
I'd tend to agree that the core should be as slim as possible, and extra functionality (including popular shortcuts) should be contained in separate downloads.
Having said that, nant::get-version() is a much more obvious function (more self-documenting) than assembly::get-version(nant::get-location()) ... the latter looks like you are getting the version for the location of nant (?!) at first glance.
I could go either way :-)
-T
------------------------------------------------------- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink & Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 _______________________________________________ Nant-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-users
