Today I was logged in remotely to my office workstation, integrating MSBuild, AspNetCompiler and nAnt. We have to transition from 1.1 to 2.0 and integrate with our current build system - a nAnt-centric, custom vss integrated copilation framework.  I was pleased that nAnt was so well written as to be able to seamlessly orchestrate the 2.0 MSBuild details.

After authoring a few nAnt scripts and getting a few succesful builds, I was completing the details of copying the results from the source directory /bin/Release to the deploymnet directory so the existing build framework would find and check them in.  I'm using .84 of nAnt so the functions and conditionals I needed weren't yet supported.  Rather then upgrade, I tried to use a property to delete the bin directory.  When the property was an empty string, I expected no deletion to occur and a message to write stating directory not specified. Rather then that, it took a little longer then expected to return, then finished without error. 

Five minutes later a folder I'd been working in disappeared.  I thought, "hmm, that's strange."  Then a dialog popped from visual studio stating that something couldn't be loaded.  Then, Windows file protection warned that files had been changed.  Everything went to crap.  I quickly killed every process I could and then rebooted.  The machine did not return.

I arrived at work to find "NTLDR is missing"...  ARGH!

Further inpection revealed that most of my c: drive was GONE!

I have been a huge fan of nAnt since I first started using it several years ago.  This is the first time anything really bad happened as a result of any software I was using (unless you count that day I tried to download the hi res smut player... ).  There is no one to sue, no one to blame, no one to hold accountable.  That is why open source software carries a high risk and some companies restrict its use.  It is a good lesson to me.  I need to be more diligent about using backed up directories on the network share.  Fortunately, all my work is in source control.  I can recreate the myriad of diagrams and presentations that were lost.  It also taught me how tranient  the output of developers really is.  I lost a lot of bits off that computer today.  Yet, I only really lost a little valuable, but recoverable, time.  The rest is in my head. So, every time some talented developer walks out the door, we lose most of what they contributed to the company.  I wish there were a way to express that and convince management of that fact.  I don't care how much documentation we do, if the developer who came up with it was talented, capable and productive, we watched our most valuable company assets stroll on down the road.

...I am not sure what was expected to be in place to prevent this from happening but there is a property (nant.project.basedir) that should have been set.  It apparently weren't...  ;>(

public string GetFullPath(string path) {

   if (StringUtils.IsNullOrEmpty(path)) {

      return BaseDirectory;

   }

...

RecursiveDeleteDirectory(dirPath);

I would have words with that developer if I knew their name... 

The last post about namespaces was just the warm up.  After I identified the situation and removed our references to the "SupportClass", I continued having issues with the build.  The error was "such_and_such referenced class in 'this_and_that.dll' inherits from baseclass 'so_and_so' that is defined in another assembly that is not referenced.  You must add a reference to ''this_and_that, version 1.0.0, culture: nuetral'

The baseclass is indeed defined in the same class as the derived class.  (Confirmed thanks to Lutz Roeder's reflector)

Why couldn't it find a ref to itself? 

As it turns out, nAnt will alphabetize your assembly references.  Execute NAnt using the -verbose flag to see such details during execution.  When looking for baseclasses, references, etc, csc.exe will inspect in the order of reference declarations.  Therefore, my namespaceless collision of {global} "SupportClass" bit me again.  What to do?

If NAnt is going to alphabetize, why not rename the offending class.  Fortunately, only one class library, Novell.Directory.Ldap.dll makes is dependent and self-referencing on its "SupportClass".  Therefore, I could rename the other dll to appear later in the alphabet.

<copy file=".${bin.dir}\Awrecka.Navigation.dll" tofile="${build.dir}${bin.dir}\ZAwrecka.Navigation.dll" />

-- compile My.Enterprise.dll -->
<csc target="library" output="${bu ... />

-- copy the Awreckadll back to its proper name and get rid of zendeca -->

<copy file="${build.dir}${bin.dir}\ZAwrecka.Navigation.dll" tofile="${build.dir}${bin.dir}\Awrecka.Navigation.dll" />

<delete file="${build.dir}${bin.dir}\ZAwrecka.Navigation.dll" />

Anyone ever heard of a  H A C K ?

 

Rick emailed me about excluding resources after finding my nAnt resources Post.  I wasn't sure about this so I googled it.  I know that nAnt will automatically compile resx files as resources.  Actually, I am not entirely sure it this is nAnt or csc.exe but, nonetheless, they will be included by default.

Excuding is available to the developer, however. 

<resources basedir="." dynamicprefix="true" />
   <include name="**\*.resx" />
   <exclude name="somefile\loginform.resx" />
</resources>

This post by punk coder has more detail and things to consider

Setting up cruise control .net is no walk in the park! This article is a HUGE help to get started, particularly for the majority of us running sourcesafe (VSS). I'll post my own experiences as well

Intro

Building a project is no big deal.  Building a solution of inter-dependent projects is also no big deal.  Building multiple versions of the same solution full of inter-dependent projects and maintaining the association between source and binaries can get hairy.

 

NAnt and VSS

I have been working with NAnt for many months, VSS for many years.  NAnt is the compile portion of an automated build system I've written that supports (hacks) the concept of “promotion” in MS Visual Source Safe.  Promotion is the idea of tagging a file version for some target release.  Using the latest code is not appropriate in a multi-project, multiple-release schedule team-environment

 

Requirements

The basic workflow is as follows...  Developer makes changes intended for particular scheduled release and checks them into VSS.  She labels the file with the build label (B1.15.02 for instance) and then notifies QA that the changes will be available in build 1.15.02.  When QA is ready for that build, build application is executed using that label and all files labeled are collated and compiled.  The result is checked into a staging directory section within VSS along with the associated source files and labeled as a snapshot.  QA stages from VSS for test.  When approved, infrastructure admins stage from the same location.  Additionally, the build app can deploy the result.  Anytime in the future, any build, from any project, compiled result and associated source, must be recoverable. 

 

Additionally, we have outgrown building everything, every time.  Reusable libraries need not be recompiled with the client but we still need to have the ability to restore the source code for the reusable library should that version require debugging.  It would be nice if this were an easy, automated process.

 

NAnt solution task

I was excited to see all the additions NAnt has had in the last several months.  I downloaded the last stable build and set up a test solution with a similar inter-dependent project configuration that we have in our real solutions.  I was able to get <solution> task to work only after allowing full writable access to the virtual directory that held the web UI project.  did not work correctly (supposed to map virtual directories to file path).  Ultimately, it built the solution but did not copy resources such as aspx pages or images to the output directory.  In fact, it ignored my specified outputdir and instead copied to the location of the build file.  Perhaps it is a symptom of being on Win 2k Pro and using framework 1.0.  I cannot control this, it is company policy that dictates what I use.  So, while it did a good job of imitating what Visual Studio does, it does not provide a viable offline build solution solution....

 

NAnt contrib. Contains Slingshot, which converts a solution file to a NAnt build file.  I’ve already done this manually but in the future may try it as a good starting place.

 

Automated Build System

Presently, my little build app can reconstruct any previous version of the application, compiled result and associated source, based on a holistic snapshot in VSS.  That means build everything, check in all the source and result, label it.  Done.  Unfortunately, building everything, every time, gets cumbersome.  So...

I am currently working on build application enhancements that enable a return to the versioned library build approach we were used to with Com and before.  Each assembly will be built atomically, all by itself, independent of the projects it depends upon or which depend upon it.  In out present application, we have assemblies that reference assemblies which also reference the assemblies the referenced assemblies reference.   Uh huh.  What if assembly (b) version 1.0 references assembly (a): version 1.2.0 and assembly (c) references assembly (b) version 1.0 and assembly (a) version 1.2.1 ?   Furthermore, what if the development manager requests a restore of the solution as of 2 months ago?  How do we identify what source code is associated with the dll in the bin directory of the client application?  My plan is to label everything, embed the version in the assembly manifest and maintain a version specific reference configuration file in the source of each project.  It's like reinventing the solution file.  I would love to use the solution file but every developer has a little variation of the solution file.  Some have project references, some use file refs, some have test projects and files.  Getting everyone to conform is harder than maintaining a master file.  I have the NAnt file, the traditional version that calls out what to build, what to copy, etc, in the source.  I will now have the additional versioned references configuration file as well.  I'd like to combine them but haven't decided if that is appropriate.  It is better to have less files and fewer steps to set up but not at the expense of complication. 

 

Back to the source-binary maintenance.  When source for a project is reconstructed from VSS, the binary (actually IL, but you get the idea) will be in the bin.  The ref-config file will tell the application where the source exists in VSS.  The application can then go get that source.  Wow, I just answered my question.  I had a dilemma and the answer just appeared.  So the config file includes the version.  During the build, I will amend the config document so it reflects the exact version, including revision, of the referenced assembly.  This will be accomplished using reflection.  References will be pulled using a version label to whatever precision is appropriate.  A reference might simply specify assembly (a) ver 1.2.  Then, the most recent 1.2 will be retrieved (maybe 1.2.345.3211).  How tightly specified the reference is should be flexible.  I will read the manifest of the assembly, retrieve the version embedded, amend the config file of the client to reflect that, and viola, any previous state can be restored in the future.

 

This deployment process has been an amazing journey for me as it has changed so frequently.  My hope is that Microsoft will consider these requirements with MS Build.  The key to having a viable build solution is supporting the ability to promote files and keep working on them.  While I love my little build app, I would gladly retire his position for something that MS supports.  On the other hand, it sure was fun to build an app that builds apps including the build app.  I wonder if I could add a code seeker to the build app and set him free in the world, randomly building applications all over the world…

 

nAnt

I will post my insights on NAnt at a later time.  For now, some quick advice:

• Use the samples.  Documentation is lacking but functionality is extensive.  Check out the samples to see what is available.
• Start simple.  Don’t try to build you company app right away.  Make the hello world app that mimics your real app on a smaller scale.  Keep it for future refinements and experiments. 
• Check out NAnt contrib.  They’ve radically improved the NAnt workspace so finding things is exponentially easier but I spent quite some time wondering why tasks wouldn’t work.
• Read the user lists

 VSS build process II.jpg (43.15 KB)<< process diagram