I thought I'd put down some notes and thoughts on the new Build Process and
Project Structure.
I'm not quite sure where to start, or what I should cover, so please excuse
any rambling, or duplication. John Simons has gone over this before, as
well. Any errors or omissions are my own. Kudos to Jono and John for setting
this up.
VS.NET and MSBuild do not work on /trunk once a project has been moved and
converted to the new structure. Mostly, this is because the directory which
holds the SNK and libs has moved, and is no longer at the same level as
before (e.g. the old method of finding binary dependencies could use a
relative path of "..\..\..\SharedLibs", while the new structure uses
"..\..\lib"). This is important because even were we to use the
$(Configuration) replacement variable in our VS.NET project files, we would
still have to do some on-the-fly manipulation of the XML to make them work
in both trees.
NAnt will continue to build /trunk, because each project will be placed back
into the old tree using svn:externals. For instance the Binder Component
used to reside in /trunk/Components/Binder, and now resides in
/Components/Binder/trunk/src, with the /Components/Binder/trunk/src folder
being added back into /trunk/Components as an svn:externals entry. The
property value for this is: "^/Components/Binder/trunk/src Binder". This
means that as long as the Binder project does not drift too far away from
it's old NAnt build files, it will continue to build in /trunk because the
components.build file will still find it within the working copy. The
working copy ends up looking identical to the old structure.
Here's the the step-by-step I used (note that the examples for the Mono libs
assume that the net-3.5 IL will work in the mono-3.5 world - there are some
projects that this is not true. You know who you are.):
1. "Create folder" (e.g. /Components/Binder).
2. Create subfolders for trunk, branches and tags (e.g.
/Components/Binder/trunk).
3. Create a lib folder (e.g. /Components/Binder/trunk/lib).
4. "Copy to..." from the old folder to a new folder called src (e.g. from
/trunk/Components/Binder to /Components/Binder/trunk/src).
5. "Delete" the old folder (e.g. /trunk/Components/Binder).
6. Add an svn:externals entry to the parent directory of the old
structure (e.g. svn:externals "^/Components/Binder/trunk/src Transaction" to
/trunk/Services).
7. Add an svn:externals to the new trunk from /buildscripts. Ignore the
build directory. (e.g. svn:externals "^/buildscripts buildscripts" to
/Components/Binder/trunk).
8. Populate the lib folder with dependencies, including Castle binaries.
Make a subdirectory for each framework target. This requires that you have a
set handy - hence the necessity of ensuring the old /trunk compiles in NAnt.
(e.g. Look at the references in the Castle.Components.Binder and
Castle.Components.Binder.Tests projects, and copy the necessary assemblies
from the build artifacts directory /trunk/build/net-3.5/release to
/Components/Binder/trunk/lib/net-3.5 and
/Components/Binder/trunk/lib/mono-3.5, respectively).
9. Replace all project-based dependencies in the primary project(s) (e.g.
replace all project-based dependencies in the Castle.Components.Binder
VS.NET project with binary references, targeting the assemblies in
/Components/Binder/trunk/lib/net-3.5).
10. Do the same with the Test project, but leave the reference to the
primary project(s) (e.g. in the Castle.Components.Binder.Tests project,
leave the project-based dependency to Castle.Components.Binder. Replace all
other project-based dependencies with binary dependencies).
11. Modify the projects to find the SNK file located in the buildscripts
folder (e.g. /Components/Binder/trunk/src/buildscripts).
12. Create and add AssemblyInfo.cs files to each project.
13. Add a default.build file to trunk/src and subdirectories (e.g.
/Components/Binder/trunk/src,
/Components/Binder/src/Castle.Components.Binder and
/Components/Binder/src/Castle.Components.Binder.Tests)
14. Configure the default.build files. Look at the projects already
migrated for an example.
15. Configure the TeamCity Project with Build Configurations. Make sure
the VCS Checkout Rule always points to a path that exists. If the project
doesn't have a release branch or tag yet, point the rule at the trunk.
16. Build Goodness locally and on TeamCity.
Once the project has been moved and converted, it will build standalone.
This is a first for Castle, and in my mind very desirable.
- rb
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Castle Project Development List" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/castle-project-devel?hl=en
-~----------~----~----~----~------~----~------~--~---
