From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Shawn Hinsey
Sent: Wednesday, August 30, 2006 4:22 PM
To: [email protected]; [email protected]
Subject: Re: [Castle-users] [OT] How to handle vendor drops and debug builds
I definitely get why you'd prefer nant to devenv - I do too.
It's just that I am trying to solve this problem in a way that is equitable to
both the more sophisticated developer and to the average codemonkey
type.
I was thinking that one could write a custom task for MSBuild that
would invoke nant.exe directly, but you could probably manage all of the
dependencies manually from MSBuild by porting your nant solution. Mostly the
ideal situation is one where you can have anyone just grab the project from
whatever source repository the company uses, perform a "Get Latest" or similar
action, and have the latest version of everything on their local machine with no
external steps. By using something like CC.NET you can manage the bulk of this
on a central server, but it'd be really nice to be able to eventually write
something that lets you manually invoke the process.
-----Original
Message-----
From: [EMAIL PROTECTED] on
behalf of G. Richard Bellamy
Sent: Wed 8/30/2006 7:08 PM
To:
[email protected]
Subject: Re: [Castle-users] [OT]
How to handle vendor drops and debug builds
Interesting idea... I'm a
little biased toward NAnt because it's been
able to do things devenv.com
couldn't do for years. One glaring issue I
see immediately is that the
process I've outlined would run for any
platform target NAnt supports (.NET
1.0,1.1,2.0 & Mono 1.0,2.0), which
msbuild cannot.
You're right
about it not taking advantage of the VS.NET solution file
infrastructure...
on the other hand, the process is geared toward taking
advantage of open
source projects, which almost always use NAnt as their
"gold" build
tool.
How would you suggest bootstrapping it out of VS using MSBuild?
I'm
asking because I suspect that whatever you do for MSBuild would
also,
with some tweaking, work with NAnt.
-
Richard
________________________________
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
