Kev Jackson wrote:
Given that there's already a NAnt for .Net development, and that
Microsoft have decided to write their own build tool (MSBuild), I
don't really see much point in having a .Net task for Ant. I doubt
very much that a pure .Net application would (and dev team) would
install a JRE + Ant + .net antlib just to build their app, when:
a - using build tools anyway just isn't part of the Microsoft/.Net
developer culture
b - there are other build tools available that don't require a JRE to
be installed
c - one of these build tools has been 'blessed' by Microsoft
The only usefulness in the ant lib would come when developing a
cross-platform/multi-platform app where you want to build everything
with one tool in which case Ant could be used to build for example a
server side component in Java and a client side component in .net
1. we have had .net tasks in ant-optional since before .net shipped.
2. I have used them in production code, doing
-<importtypelib> to import a COM typelib to .NET binaries
-ildasm to disassemble that typelib to .asm file
-replaceregexp to patch the .asm file so that it imports arrays properly
-ilasm to import the stuff.
3. I've also used the <wsdltodotnet> and <csc> to make the client side
code for a SOAP endpoint. The easier we make it for people to do such
interop testing, the more chance people will actually write web
services that work with multiple platforms.
ok can't argue with that
The .NET tasks also have mono support; you can build this stuff on a
unix box, the goal being that gump will do mono code too.
Is that actually one of the goals of gump, to build Mono code?
I dont fully get the mono project. I agree with some of their points
-linux needs to move beyond C/C++
-tight OS integration is good for those apps that dont care about
portability
-language independent type systems is good for reusable libraries
but I dont see the need to do a 100% clone of the .NET stack, including
Windows Forms and MSBuild. Sometimes you have to draw the line.
I also think the linux community would be better served by a project
working on decent java/OS integration, the way apple did for java1.4. We
need drag and drop between the filesystem and swing apps to work. we
need swing to work. we need java apps to subscribe to dbus events. Sun
are not going to do this, no matter what they say, linux is not
strategic right now.
I agree, Ant wont get much traction in .NET land because they live in
their own world, a world with MSBuild if you follow the VS roadmap,
NAnt if you dont. But the .NET antlib is designed to shell out to
those build files, letting you build the different bits of your
project in the language of your choice.
ouch /me feels the pain! Great rebuttal there, I can definitely see the
need to keep it around :)
one thing we could do is move all .NET tasks into the net antlib, and
take them out the core distro. They are somewhat niche, which I have to
say, is probably a good thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
