.NET tasks
Introduction
Ant support for .NET goes back to before .NET was released, and
continues to be expanded based on user demand. Users writing nothing but
a .NET application, may want to look at the .NET-based
NAnt project, that supports
both the Microsoft and the Ximian managed Mono project's implementation of the
.NET framework.
Over time, the .NET tasks in Ant have tended to evolve to meet a few
limited needs. Firstly, developers working with complex deployment problems may
want to use ant to use the fairly advanced deployment tasks Ant ships
with. Secondly, anyone who has a cross-platform project can use these
tasks to cover the .NET side of the problem. Here, cross-platform can
mean more than just Java and .NET: the C++ tasks in the ant-contrib
project on sourceforge can be used with Ant to do native C++ and .NET
cross development if that is your need. Finally, Ant support for .NET
lets one automate .NET development under an automated build process,
such as AntHill or Cruise Control.
What this means is that the Ant tasks for .NET support do not get as
much rigorous use as the Java tools, and are evolving more slowly -that
includes the time for support calls to change. But as a consequence,
developers working on .NET support have more freedom to play around with
the code. It also means that the fairly unusual set of tasks supported
by ant enable a few interesting operations that can not be performed any
other way:
- Integrating with a Java based SOAP Service -generating C# code from
the server's WSDL and running it against the server.
- Building and deploying a C#-based Web Service, then using the Apache
Axis tasks to create JUnit tests to call the endpoints.
- Patching .NET type libraries to work with more complex IDL than the
basic <importtypelib> wrapper around tlbimport supports. Hence the
disassembler and the reassembler.
Needless to say, possible does not mean easy.
Chapter 15 of
Java Development with Ant covers the first of these, using the Ant1.5
version of the tasks. Going the other way -generating Java client
code and JUnit testcases is covered in
The Wondrous curse
of Interop. The final trick, IDL and Typelib abuse, is not
documented as we do not want to encourage such an ugly practice. It,
can, however, be done if absolutely necessary. The trick is a sequence
of <importtypelib/>, <ildasm>, <replace> and finally
<ilasm>.
Task List
| Csc |
Compiles C# code |
| vbc |
Compiles VB.Net code |
| jsharp |
Compiles J# files |
| ildasm |
Disassembles .NET executables and libraries |
| ilasm |
Assembles .il files |
| WsdlToDotnet |
Generates .NET code (C# or VB) from a WSDL file |
| ImportTypelib |
Imports a COM type library into .NET |
Change Log
Ant1.6
This revision goes along with NET 1.1, though there is no reason why
it should not work on other versions.
- vbc task
- jsharp task
- mono support
- ilasm
- tlbimport
- Reference filesets in the compiler tasks
- definitions in the compiler tasks
- multiple source filesets in the compiler tasks. If these are used, the
implicit fileset is disabled
The compile tasks: vbc, jsharp, and csc, all contain lots of common code
in a shared base class: if you can use one you should be able to use
another.
Ant 1.5
This revision goes along with NET 1.0 (SP1)
- CSC: added filealign
- CSC: added reference to office.dll
- CSC: dependency checking! only if destFile is set!
- WsdlToDotnet written
Version 0.4
This is the beta-2 revision of the tasks.
- ILASM: pulled the owner attribute, added keyfile for giving binaries a strong name
(MD5 hash of the checksum)
- CSC: added win32res , noConfig, utf8output, fullpaths
- CSC:
Version 0.3
The changes here reflect Beta-1 of the dotnet SDK and experience of use in
more complex projects. This build does not work with the older SDK,
primarily because the automatic reference feature references libraries
only found in the new SDK version.
External changes
- Recursive inclusion of .cs and .il files
- Documentation enhanced, includes examples and details of all parameters
- The csc task automatically includes the common dotnet assemblies, so
there is no need to remember to refer to 'System.dll', 'System.Web.Services',
etc. This feature can be disabled by setting the 'includeDefaultReferences'
flag to false.
- References can also be referred to using the ReferenceFiles parameter, which
is an ant path specification. The old 'references' string is still retained.
- An 'extraoptions' attribute enables the build file to include any CSC options
which are not explicitly supported in the CSC task.
Internal changes
- Some minor refactoring (move common code a method)
- Application of Jedits JavaStyle task resulted in a major reshaping of
the codebase and the insertion of a blank line every second line. Significant
effort was required to revert some (but not all) changes.
- Removed throws clause from methods which can't throw exception
Change Log
Ant1.6
This revision goes along with NET 1.1, though there is no reason why
it should not work on other versions.
- vbc task
- jsharp task
- mono support
- ilasm
- tlbimport
- Reference filesets in the compiler tasks
- definitions in the compiler tasks
- multiple source filesets in the compiler tasks. If these are used, the
implicit fileset is disabled
The compile tasks: vbc, jsharp, and csc, all contain lots of common code
in a shared base class: if you can use one you should be able to use
another.
Version 0.5
This revision goes along with NET 1.0 (SP1)
- CSC: added filealign
- CSC: added reference to office.dll
- CSC: dependency checking! only if destFile is set!
- WsdlToDotnet written
Version 0.4
This is the beta-2 revision of the tasks.
- ILASM: pulled the owner attribute, added keyfile for giving binaries a strong name
(MD5 hash of the checksum)
- CSC: added win32res , noConfig, utf8output, fullpaths
- CSC:
Version 0.3
The changes here reflect Beta-1 of the dotnet SDK and experience of use in
more complex projects. This build does not work with the older SDK,
primarily because the automatic reference feature references libraries
only found in the new SDK version.
External changes
- Recursive inclusion of .cs and .il files
- Documentation enhanced, includes examples and details of all parameters
- The csc task automatically includes the common dotnet assemblies, so
there is no need to remember to refer to 'System.dll', 'System.Web.Services',
etc. This feature can be disabled by setting the 'includeDefaultReferences'
flag to false.
- References can also be referred to using the ReferenceFiles parameter, which
is an ant path specification. The old 'references' string is still retained.
- An 'extraoptions' attribute enables the build file to include any CSC options
which are not explicitly supported in the CSC task.
Internal changes
- Some minor refactoring (move common code a method)
- Application of Jedits JavaStyle task resulted in a major reshaping of
the codebase and the insertion of a blank line every second line. Significant
effort was required to revert some (but not all) changes.
- Removed throws clause from methods which can't throw exceptions
The test harness has been expanded to include unicode source file
(the build works but the rest of the system has 'issues' with high unicode
package and method names)
Version 0.2
First public edition, added to the ant cvs tree. Tested on the PDC build of
the dotnet SDK only, and still immature. The command execution code was
refactored out into a 'NetCommand' class for re-use. The Ilasm task was added
at this time.
Version 0.1
Initial proof of concept; very rudimentary support for CSC only.
s
The test harness has been expanded to include unicode source file
(the build works but the rest of the system has 'issues' with high unicode
package and method names)
Version 0.2
First public edition, added to the ant cvs tree. Tested on the PDC build of
the dotnet SDK only, and still immature. The command execution code was
refactored out into a 'NetCommand' class for re-use. The Ilasm task was added
at this time.
Version 0.1
Initial proof of concept; very rudimentary support for CSC only.
Copyright © 2000-2003 Apache Software Foundation. All rights
Reserved.