From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Hinsey
Sent: Wednesday, August 30, 2006 3:51 PM
To: [email protected]; [email protected]
Subject: Re: [Castle-users] [OT] How to handle vendor drops and debug builds
I think one of the biggest problems with this is how it fits
into the workflow "average developer." Have you tried to integrate this process
into Visual Studio? I wonder if you couldn't bootstrap it out of VS using
MSBuild...
-----Original Message-----
From:
[EMAIL PROTECTED] on behalf of G. Richard
Bellamy
Sent: Wed 8/30/2006 6:43 PM
To:
[email protected]
Subject: [Castle-users] [OT] How to
handle vendor drops and debug builds
I'm following up on a thread that
was mentioned some time ago about how
people handle vendor drops,
dependencies, and stepping into vendor
source during debugging of a working
copy of your own code.
Others mentioned that they would be interested in
the process I use to
keep it all straight, and I'm attaching two documents
that help explain
what I do, as well as the vendors.build file I am currently
using on one
of my projects that uses Castle.
In addition to those
documents, I have a comment, and a disclaimer:
1. The process is
inherently brittle, as it relies on my manually
maintaining my vendors.build
file properly. Any change in the upstream
source/dependency, and things can
get real messy very quickly. Something
that could manage this automatically
would be great, but I have yet to
find something like Maven for .NET
(although I did find a Maven plug-in
for .NET, it's not the same
thing).
2. This is a work in progress, and as such, I'm very open
to
suggestions. Be gentle. :)
THE PROCESS:
The goal of the
process is to be able to step into vendor code, at will,
if the vendor source
is available. In addition, one should be able to
switch dependencies from
debug to release with relative ease.
The key to this process is the
vendors.build file.
To ensure you can switch dependencies from release to
debug and back
again, you use the vendors.build to purge and recreate a
vendors library
directory, which is the only location for dependencies
outside of your
own source. Basically, regardless of whether the dependencies
derive
from source or are from a binary distribution, they end up in the
same
location, "vendors/lib", and then categorized by the NAnt
function
"${framework::get-target-framework()}", i.e.
"vendors/lib/net-2.0".
Within the vendors.build file you have targets
which can build either
release or debug of the vendor source, with whatever
granularity you
desire. As well, the vendors.build file is responsible for
updating the
shared/vendors library directories of the vendor sources
themselves,
just in case one of your vendor builds is also a dependency of
another
of your vendors.
So, for instance, in a project that has
Castle.ActiveRecord as a
dependency, I will have the source for both Castle
and NHibernate. I
ensure NH is built first, and that the Castle SharedLib
directory for NH
is updated with the build product. In addition, if I wanted
to use the
newest version of log4net, but I didn't want to compile it from
source,
it would be located within my "vendors/bin/log4net/net-2.0"
directory
(or some such), and would be placed in the appropriate NH and
Castle
directories before their respective compile processes to ensure
a
consistent version of log4net across all builds.
Of course, you have
to be really careful if you have commit access to an
upstream vendor tree,
and that tree includes the shared library
directory - you need to make sure
you NEVER commit the updated
dependencies in the shared library directory
into the tree, for obvious
reasons.
------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________ CastleProject-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/castleproject-users
