all valid points. However I think its important to get somthing people can use right away. NAnt.Optional is a good catch all for extra tasks and we can move them gradually
Will you first make a proposal for incorporating the NAntContrib tasks into NAnt regarding source location, namespace and perhaps class name (don't know if we'll be needing to change class names as well, though).
eg. right now, the vss tasks are in a separate namespace in NAntContrib, but
we have no(t yet a) separate namespace for the cvs tasks. we should try to
make it all consistent, I think
to different namespaces/assemblies as appropriate. End users don't care which assembly/namespace a task resides in as long as it works.
I will draw up a list of which tasks I think can be slotted into the existing nant task namespaces and I'll post it so that people can add to it.
I'm fairly sure that the interop assembly contains the typelib, interface and clsid GUIDs from the source typelib. So if the implementation of the COM interface is updated but the guids not changed it will still work. Sourcesafe is also specific to win32 - so that isn't really an issue. I don't know about starteam though.why ? how else do you propose to connect to com code ? Sorry, but
forgoing a perfectly good COM based api to wrap a command line tool
seems completely backward to me. I don't understand the problem you have
with interop assemblies - they are simply metadata and mappings that
allow you to call COM objects. Is there somthing inherently evil about
them that I don't know about ? Feel free to write wrappers in managed
c++ if you want.
The problem I have with COM interop assemblies is that they are linked to a specific version of the COM interface, and that they are specific to win32. Well, I know command-line interfaces can change too between versions, but you could still deal with that yourself.
we can update the interop assembly when the interface changes.
Up until now, we've always tried to create wrappers around command-linenot in all cases. We have done for the sdk tools and compilers- the reasoning there being that :
tools as these will likely be more portable, and I really think that's a
good strategy after all.
we didn't want to be bound to a specific framework version for those tools. ie if we use the .exe then changing frameworks is only a matter of pointing at a different directory - as opposed to binding to different assemblies.
since the compilers are commonly used on the commandline we wanted to ensure that the output was the same from nant as form the commandline.
for cvs and zip we already bind to libraries - although they aren't COM ones.
But if you think that using the COM interop assembly is the way to go, thenwell I just don't have an issue with it and its the implementation we have. If what we had was a wrapper around a sourcesafe commandline tool then I'd probably be happy with that too.
that's fine by me.
Ian
------------------------------------------------------- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa00100006ave/direct;at.asp_061203_01/01 _______________________________________________ NAntContrib-Developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nantcontrib-developer
