Re: [Nant-users] newbie first post

[stephan]

Hi Clive,

being a newbie myself, I might have the insights you were looking for <g>.
See my remarks inline.

[EMAIL PROTECTED] wrote on 21/02/2005 22:55:38:

> I'm just about to start an eval of NANT.     A few kick-off questions...
>
> Right now, I'm unsure of the scope of NANT in terms of how
> appropriate it is to a mixed environment with some .NET apps and
> older legacy VB6 apps - most apps with SQL Server as a back-end.  
> Some of my developer colleagues as asking me how '.NET' centric NANT
> is?   In other words, is it a build tool for .NET apps or is it a
> build tool suitable for non-.NET apps which just happens to be
> written using .NET?
Nant envolved from it's conceptual anchestor ANT which is rooted in Java. It was build to better fit the needs of the dotNET community. While it serves special features for dotNET like targeting different framework version, it is in deed a general purpose build tool. I succesfully integrated tasks for NSIS (installer) and THINSTALL (packageing and obfuscation) with NANT. I love the ZIP tasks. Every release build ends up in a time-stamped ZIP file for additional backup.
   
>
> In our environment, a mixture of VB6 and .NET on top of SQL Server,
> is NANT the best bet?
Asks the vendors of commercial tools... just kidding. I think you should give NANT a shot to get used to continous integration and the usage of built scripts. You will see that it covers most of your needs. Even if you might decide, that it is not the final answer to your needs, NANT will sharpen your understanding of the built process, so you have preciser criteria for selecting your tool (while I think you will stick to nant anyway). You will very fast start to appreciate what NANT contribute has to offer.

>
> If NANT is the way to go on this, how can we best integrate the
> associated SQL Server builds into this process?
Use NANT contribute, there you have the SQL task. Pull your schema from the actual db into the version control and run it against a test database. You will very fast come to a point where you have a close look at NUnit and something for VB (see: http://c2.com/cgi/wiki?TestingFramework ) and TSQL.

>
> Is CruiseControl seen as the best partner for NANT in terms of
> automated/continuous build process?
CruiseControl works very well with NANT. What happens often: You run NANT locally BEFORE you commit your part of work into the VersionControl (and if the tests pass, you submit automatically) and then CruiseControl runs the same script as part of a larger integration build on the server. Again getting started is more important than the initial tool selection!!! Memento Bene: Refactoring concepts are also valid for your tool selection, not only your sourcecode.

>
> Which SCM tool fits best into the NANT/CruiseControl picture?   n.b.
> using VSS right now but developers see its shortcomings.
Subversion is very popular and NAnt contribute supports it very well. When you come from a VSS background you might want to try VAULT (commercial). Perforce and PVCS are suppoted too. My best bet: try Subversion.
I would use cruisecontrol (but that is mainly because we have .net and java projects, so we run cruisecontrol and cruisecontrol.net... less to learn). We also like maven, but that's not ready for dotNET yet (C# is already supported).

>
> I have a pilot implementation of one of our services that includes
> vb6 and SQL Server with the vb client interface being currently
> rolled out using a script that constructs the MSI package.   My aim
> is to see all components of the build including SQL Server together
> in the same build process.   As a starting point for me, are there
> any examples I could refer to for this scenario using the tools I
> have already mentioned plus any more that might be necessary?  
For the MSI package you might have a look at Microsofts Open Source Package MSI2SQL on sourceforge. There you can create an MSI package from an XML definition. The XML Definition would be generated by build tasks (Unfortunatly VB6 projects are not in XML format, you might add some scripts.
A personal favorite: we use THINSTALL(.com) to bundle all needed files into one exe (including the VB6 runtime. It somes with a virtual registry. So we end with one exe that can be xcopy deployed. I also would recommend to have one build process creating seperate client and server scripts.

You find bits and pieces over time. We like visustin (http://www.aivosto.com/visustin.html ) to document our SQL. It doen't run form a command line (yet) but the author has promised to include that feature somewhen this year.
When you look at NDoc you for sure wish for a lot of CPU power and will confine the doc generation to nightly builds. I'm not sure if there is support for VB6.
There is SQLdoc for your SQL on the server: http://www.codeproject.com/cs/database/sqldoc.asp

Hth
:-) stw
>
>
> Thanks in advance,
>
> Clive R.