This task sets a property to the name of a temporary file. Unlike the Java1.2 method to create a temporary file, this task does work on Java1.1. Also, it does not actually create the temporary file, but it does guarantee that the file did not exist when the task was executed. <p> Examples <pre><tempfile property="temp.file"/></pre> create a temporary file <pre><tempfile property="temp.file" suffix=".xml"/></pre> create a temporary file with the .xml suffix. <pre><tempfile property="temp.file" destDir="build"/></pre> create a temp file in the build subdir
This task sets a property to the name of a temporary file. Unlike the Java1.2 method to create a temporary file, this task does work on Java1.1. Also, it does not actually create the temporary file, but it does guarantee that the file did not exist when the task was executed. <p> Examples <pre><tempfile property="temp.file"/></pre> create a temporary file <pre><tempfile property="temp.file" suffix=".xml"/></pre> create a temporary file with the .xml suffix. <pre><tempfile property="temp.file" destDir="build"/></pre> create a temp file in the build subdir
Compiles C# source into executables or modules. csc.exe on Windows or mcs on any other platform must be on the execute path, unless another executable or the full path to that executable is specified in the <tt>executable</tt> parameter <p> All parameters are optional: <csc/> should suffice to produce a debug build of all *.cs files. However, naming an <tt>destFile</tt>stops the csc compiler from choosing an output name from random, and allows the dependency checker to determine if the file is out of date. <p> The task is a directory based task, so attributes like <b>includes="*.cs" </b> and <b>excludes="broken.cs"</b> can be used to control the files pulled in. By default, all *.cs files from the project folder down are included in the command. When this happens the output file -if not specified- is taken as the first file in the list, which may be somewhat hard to control. Specifying the output file with <tt>destFile</tt> seems prudent. <p> <p> For more complex source trees, nested <tt>src</tt> elements can be supplied. When such an element is present, the implicit fileset is ignored. This makes sense, when you think about it :) <p> References to external files can be made through the references attribute, or (since Ant1.6), via nested <reference> filesets. With the latter, the timestamps of the references are also used in the dependency checking algorithm. <p> Example <pre><csc optimize="true" debug="false" docFile="documentation.xml" warnLevel="4" unsafe="false" targetType="exe" incremental="false" mainClass = "MainApp" destFile="NetApp.exe" > <src dir="src" includes="*.cs"/> <reference file="${testCSC.dll}"/> <define name="RELEASE"/> <define name="DEBUG" if="debug.property"/> <define name="def3" unless="def3.property"/> </csc> </pre>
Compiles C# source into executables or modules. csc.exe on Windows or mcs on any other platform must be on the execute path, unless another executable or the full path to that executable is specified in the <tt>executable</tt> parameter <p> All parameters are optional: <code><csc/></code> should suffice to produce a debug build of all *.cs files. However, naming an <tt>destFile</tt>stops the csc compiler from choosing an output name from random, and allows the dependency checker to determine if the file is out of date. <p> The task is a directory based task, so attributes like <b>includes="*.cs" </b> and <b>excludes="broken.cs"</b> can be used to control the files pulled in. By default, all *.cs files from the project folder down are included in the command. When this happens the output file -if not specified- is taken as the first file in the list, which may be somewhat hard to control. Specifying the output file with <tt>destFile</tt> seems prudent. <p> <p> For more complex source trees, nested <tt>src</tt> elements can be supplied. When such an element is present, the implicit fileset is ignored. This makes sense, when you think about it :) <p> References to external files can be made through the references attribute, or (since Ant1.6), via nested <code><reference></code> filesets. With the latter, the timestamps of the references are also used in the dependency checking algorithm. <p> Example <pre><csc optimize="true" debug="false" docFile="documentation.xml" warnLevel="4" unsafe="false" targetType="exe" incremental="false" mainClass = "MainApp" destFile="NetApp.exe" > <src dir="src" includes="*.cs"/> <reference file="${testCSC.dll}"/> <define name="RELEASE"/> <define name="DEBUG" if="debug.property"/> <define name="def3" unless="def3.property"/> </csc> </pre>
Assembles .NET Intermediate Language files. ilasm.exe must be on the execute path, unless another executable or the full path to that executable is specified in the <tt>executable</tt> parameter <p> <p> All parameters are optional: <il/> should suffice to produce a debug build of all *.il files. The option set is roughly compatible with the CSharp class; even though the command line options are only vaguely equivalent. [The low level commands take things like /OUT=file, csc wants /out:file ... /verbose is used some places; /quiet here in ildasm... etc.] It would be nice if someone made all the command line tools consistent (and not as brittle as the java cmdline tools) <p> <p> The task is a directory based task, so attributes like <b>includes="*.il" </b> and <b>excludes="broken.il"</b> can be used to control the files pulled in. You can also use nested <src> filesets to refer to source. <p>
Assembles .NET Intermediate Language files. ilasm.exe must be on the execute path, unless another executable or the full path to that executable is specified in the <tt>executable</tt> parameter <p> <p> All parameters are optional: <code><il/></code> should suffice to produce a debug build of all *.il files. The option set is roughly compatible with the CSharp class; even though the command line options are only vaguely equivalent. [The low level commands take things like /OUT=file, csc wants /out:file ... /verbose is used some places; /quiet here in ildasm... etc.] It would be nice if someone made all the command line tools consistent (and not as brittle as the java cmdline tools) <p> <p> The task is a directory based task, so attributes like <b>includes="*.il" </b> and <b>excludes="broken.il"</b> can be used to control the files pulled in. You can also use nested <src> filesets to refer to source. <p>
@@ -66,7 +66,7 @@ timeout specified for the task as a whole. It also has a <tt>string</tt>
attribute, which is an alternative to specifying the string as
a text element.
</p>
<i>It is not necessary to declare a closing <read> element like for the Telnet task. The connection is not broken until the command has completed and
<i>It is not necessary to declare a closing <code><read></code> element like for the Telnet task. The connection is not broken until the command has completed and
the input stream (output of the command) is terminated.
This task compiles Visual Basic.NET source into executables or modules. The task requires vbc.exe on the execute path, unless it or an equivalent program is specified in the <tt>executable</tt> parameter <p> All parameters are optional: <vbc/> should suffice to produce a debug build of all *.vb files. <p> The task is a directory based task, so attributes like <tt>includes="**\/*.vb"</tt> and <tt>excludes="broken.vb"</tt> can be used to control the files pulled in. By default, all *.vb files from the project folder down are included in the command. When this happens the destFile -if not specified- is taken as the first file in the list, which may be somewhat hard to control. Specifying the output file with <tt>destfile</tt> is prudent. </p> <p> Also, dependency checking only works if destfile is set. As with <csc> nested <tt>src</tt> filesets of source, reference filesets, definitions and resources can be provided. <p> Example </p> <pre><vbc optimize="true" debug="false" warnLevel="4" targetType="exe" definitions="RELEASE" excludes="src/unicode_class.vb" mainClass = "MainApp" destFile="NetApp.exe" optionExplicit="true" optionCompare="text" references="System.Xml,System.Web.Xml" > <reference file="${testCSC.dll}"/> <define name="RELEASE"/> <define name="DEBUG" if="debug.property"/> <define name="def3" unless="def2.property"/> </vbc> </pre>
This task compiles Visual Basic.NET source into executables or modules. The task requires vbc.exe on the execute path, unless it or an equivalent program is specified in the <tt>executable</tt> parameter <p> All parameters are optional: <code><vbc/></code> should suffice to produce a debug build of all *.vb files. <p> The task is a directory based task, so attributes like <tt>includes="**\/*.vb"</tt> and <tt>excludes="broken.vb"</tt> can be used to control the files pulled in. By default, all *.vb files from the project folder down are included in the command. When this happens the destFile -if not specified- is taken as the first file in the list, which may be somewhat hard to control. Specifying the output file with <tt>destfile</tt> is prudent. </p> <p> Also, dependency checking only works if destfile is set. As with <code><csc></code> nested <tt>src</tt> filesets of source, reference filesets, definitions and resources can be provided. <p> Example </p> <pre><vbc optimize="true" debug="false" warnLevel="4" targetType="exe" definitions="RELEASE" excludes="src/unicode_class.vb" mainClass = "MainApp" destFile="NetApp.exe" optionExplicit="true" optionCompare="text" references="System.Xml,System.Web.Xml" > <reference file="${testCSC.dll}"/> <define name="RELEASE"/> <define name="DEBUG" if="debug.property"/> <define name="def3" unless="def2.property"/> </vbc> </pre>
Converts a WSDL file or URL resource into a .NET language. Why add a wrapper to the MS WSDL tool? So that you can verify that your web services, be they written with Axis or anyone else's SOAP toolkit, work with .NET clients. This task is dependency aware when using a file as a source and destination; so if you <get> the file (with <code>usetimestamp="true"</code>) then you only rebuild stuff when the WSDL file is changed. Of course, if the server generates a new timestamp every time you ask for the WSDL, this is not enough...use the <filesmatch> <condition> to to byte for byte comparison against a cached WSDL file then make the target conditional on that test failing. See "Creating an XML Web Service Proxy", "wsdl.exe" docs in the framework SDK documentation
Converts a WSDL file or URL resource into a .NET language. Why add a wrapper to the MS WSDL tool? So that you can verify that your web services, be they written with Axis or anyone else's SOAP toolkit, work with .NET clients. This task is dependency aware when using a file as a source and destination; so if you <code><get></code> the file (with <code>usetimestamp="true"</code>) then you only rebuild stuff when the WSDL file is changed. Of course, if the server generates a new timestamp every time you ask for the WSDL, this is not enough...use the <code><filesmatch></code><code><condition></code> to to byte for byte comparison against a cached WSDL file then make the target conditional on that test failing. See "Creating an XML Web Service Proxy", "wsdl.exe" docs in the framework SDK documentation
Thank you for your continuous support to the Openl Qizhi Community AI Collaboration Platform. In order to protect your usage rights and ensure network security, we updated the Openl Qizhi Community AI Collaboration Platform Usage Agreement in January 2024. The updated agreement specifies that users are prohibited from using intranet penetration tools. After you click "Agree and continue", you can continue to use our services. Thank you for your cooperation and understanding.
Stefan Bodewig