Brass Tilde wrote:
I'm not positive (we avoid inter-project dependencies like the plague
around here)
How do you handle a lower level framework, such as a data access layer,
that is used by multiple applications?
All of our shared components are built at a binary level and moved into
a single location; all top-level projects refer directly to the binary
versions only. Our NAnt build goes through the shared components one at
a time, builds it and copies it out to the \bin folder before we build
anything that requires it.
This approach does present some minor annoyances, which initially balked
at when our team leads set up this system, but after using it for a few
years, I have to admit that it seems to bypass any issues with
out-of-order project dependencies or circular cross-references or
mismatched versions or accidental regressions. On the automated-build
side, it makes building specific projects easier, since we can assume at
any given point that all of a project's references are present and
buildable. On the development side, it gives us the ability to have
multiple versions of a given component (we version the \bin folder by
major.minor versions of everything) and to make changes to shared
component projects without affecting everything that references them.
but I believe that's the functionality that's missing from msbuild.
Nope. Works just fine. I'm at a loss to explain this attitude. Either
we've been doing something different from everyone who's mentioned a
problem, or we *aren't* doing something they are.
The confusion you're having is that <solution> the task doesn't require
you to HAVE a real solution file. In some places I've worked, we were
strictly forbidden to check .sln files into VSS (I never got a straight
answer as to why, though I do wish Visual Studio wasn't so quick to
automatically load solution files without telling you :x) Instead of a
solution file, you can do something like:
<solution>
<projects basedir="C:\Projects">
<include name="Project1/**/*.csproj" />
</projects>
</solution>
And the solution task will scan the list of projects and build its own
dependency tree, including any hard references to another project's
\bin\debug or \bin\release folder, and build the projects in the correct
order.
Again, I don't do this personally, so I might have some specifics wrong,
but this is what I believe is the "missing" functionality of the
<solution> task... that is, you can't just pass 9 project file names on
the command line to msbuild and automatically have it do the right thing.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
