"many people don't really know how to use the full feature set of
their toolchain"???
I am providing feedback here for just this reason. I know a thing or
two about builds (http://www.amazon.com/Inside-Microsoft%C2%AE-Build-
Engine-PRO-Developer/dp/0735626286/ref=pd_bbs_sr_1?
ie=UTF8&s=books&qid=1234241861&sr=8-1).
Are you normally this rude to guys who sign up specifically to this
group to post a comment?
Solution files are not meant for production builds, they are for the
developer experience inside of Visual Studio. You stated the there may
be some inconsistencies between a build from your build script and
what the developer builds locally. This is normally the case anyways,
this is why there is the concept of a local build (i.e. what a
developer executes locally) and a public (team) build (i.e. what the
build server does). Are your developers building in Release mode with
all the config files that are going into production and executing all
the other steps that are needed for a public build?
I chose not to rely on some of CCNets features not because I am
ignorant to them, but because I realize that tomorrow I could be using
another technology (which I'm actually using Team Build right now),
also because the CCNet config files are not typically versioned along
with the source. Another reason is that the developer cannot execute
the build locally. Devs should be able to run the build script locally
to diagnose any issues. I don't think that installing and
configuration CCNet locally is a good option for those guys.
FYI pre/post build events should not be used. They are only supported
for backwards compatibility. So if you are using them I would suggest
that you ditch those for a full fledged MSBuild approach.
Sayed Ibrahim Hashimi
On Jul 1, 9:05 pm, Sam Calder <samuel.cal...@gmail.com> wrote:
> Everyone's entitled to their own approach, and if you want the ability to
> custom-configure your own project list/dependencies then of course ccnet
> will let you do so. But by duplicating that information you then have the
> overhead of making sure they are always kept in sync, or risk have
> development and integration builds compile two different packages... IE.
> what your devs build winds up not matching what CCNet builds for release.
>
> You may have valid reasons for your own approaches of course. But I suspect
> many people don't really know how to use the full feature set of their
> toolchain... eg. pre/postbuild events and (if required) solution
> dependencies can handle any "before or after" steps you need. And your ccnet
> config itself can do unit testing / analysis / etc... with a good selection
> of build-in tasks, and a good deal more via NAnt tasks, and then anything
> you can run from a commandline as an exec.
>
> (this is a general comment from experience, not aimed at anyone in this
> thread) CCNet's flexibility is great, but too many people do it the hard way
> out of ignorance, and without thinking about maintainability of the build
> process and ease-of-use for the whole development team... and wind up just
> making more work for everybody. In fact I think that's what gives CCNet it's
> reputation as being "hard to configure". It should be really simple and
> straightforward in most scenarios - there are many sensible defaults so a
> complex build process can still be run from a short and sweet config file.
> IMHO as a developer, a config file really should be easier to work with than
> the more restrictive gui config tools of the alternatives...
>
> - Sam.
>
> On Tue, Jun 30, 2009 at 11:21 PM, Sayed Ibrahim Hashimi <
>
> sayed.hash...@gmail.com> wrote:
>
> > I would suggest that you create a project file (i.e. .proj) which
> > builds all of your projects (i.e. csproj). This way you can have
> > control over the build process. In many cases you will want to perform
> > steps before or after a set of projects were built. With solution
> > files you will not really be able to do this, but with your own .proj
> > file you can. You may want to do some other things like code
> > generation, code analysis, unit testing, signing, versioning, etc.
> > Which is done much easier inside an enclosing .proj file.
> > Basically I use solution files for developer use in Visual Studio
> > only. Custom .proj files for all builds.
>
> > Sayed Ibrahim Hashimi
>
> > On Jun 29, 2:39 pm, ogaz <mobile1j...@gmail.com> wrote:
> > > Thanks for the reply and I agree with your use of the technologies
> > > (and totally understood the work/family/etc time juggle!) due to
> > > needs, constraints, etc. Let me briefly explain how we are using, due
> > > to our specific needs: for our build system/server, we use CCNet and
> > > MSBuild (not Visual Studio) as the fundamental technologies for
> > > building (we use other tools like NUnit, WATIN, FxCop, etc, as well),
> > > for the same reason you use CCNet and NAnt: the flexibility it
> > > provides. Though there are other significant reasons we do not build
> > > using a .sln file in our build system/server, one big reason we do not
> > > is because of the inflexibility and "black box" view it limits us to.
>
> > > Thanks,
> > > Paul
>
> > > On Jun 22, 4:06 am, Craig <cj.sutherl...@xtra.co.nz> wrote:
>
> > > > HiOgaz,
>
> > > > I can put in a quick comment from the CC.NET developers - we use a
> > > > build script (Nant) for building CC.NET. Basically, there are three
> > > > reasons we use this approach:
> > > > 1) It provides a lot more functionality than just building the
> > > > projects
> > > > 2) It is cross platform (we also use it for building CC.NET on Mono)
> > > > 3) It doesn't require installing VS on the build machine
>
> > > > From a personal approach, I also use build scripts at my work. Using
> > > > VS to build the final solution is just too limited, especially
> > > > considering all the other things that go into producing a good
> > > > software product. The only time I would use VS for building is during
> > > > development (i.e. on my machine), I never use it on the build server.
>
> > > > And of course, as a final note, one of the goals we have with CC.NET
> > > > is providing complete flexibility. We don't try to constrain people to
> > > > develop in certain ways (i.e. VS vs. build scripts). Unfortunately,
> > > > the trade off is CC.NET is a bit more complex to configure than some
> > > > of the other alternatives.
>
> > > > And sorry for the late reply, it's getting harder to juggle family,
> > > > work and open source stuff.
>
> > > > Craig
>
> > > > On Jun 20, 5:15 am,ogaz<mobile1j...@gmail.com> wrote:> I have
> > appreciated the comments on this thread. Thank you.
>
> > > > > The one fundamental, simple requirement of a good build system, IMO,
> > > > > is easy understanding (by developers, not just a "build master",
> > > > > "build engineer", "build group", etc, and not via some tribal/group
> > > > > knowledge or required translation) of why a build is broken. This
> > > > > alone, IMO, is a huge reason for building with project files.
> > > > > Investment of time into building a good build system will pay off
> > > > > exponentially; a goal should be ease for the developers at the
> > expense
> > > > > of the build system creation, not ease of the creation of the build
> > > > > system at the expense of ease for the developers.
>
> > > > > All this said, I have to say that the conclusion for me, at least, is
> > > > > "to each is own", depending on needs, constraints, requirements, etc.
> > > > > There are some points made that I would think most of us understand -
> > > > > they are a given (e.g. not having static paths) - but we live in a
> > > > > real world, with real conditions and real problems. I was hoping to
> > > > > learn something new, something that would undoubtedly sway me to
> > build
> > > > > using the solution file instead of project files, but I have not.
>
> > > > > Though I wish I would've heard from more people than just the very
> > few
> > > > > (three?) that did appreciatively take the time to reply, with more
> > > > > varying degrees of experience, I very much appreciate the replies on
> > > > > this thread.
>
> > > > > Thanks!
>
> > > > > On May 8, 11:12 pm, Sam Calder <samuel.cal...@gmail.com> wrote:
>
> > > > > > To clarify, I was talking about building solutions via CCNET.
>
> > > > > > * Build breakages should be the exception, rather than the rule.
> > You CAN see
> > > > > > what broke via the dashboard - look at the build log, see what
> > files were
> > > > > > checked in since the last successful build, etc. Sure it takes more
> > than one
> > > > > > single click, but its not a regular occurrence so no excuse for
> > being lazy.
> > > > > > Plus you can easily see the actual build error messages, same ones
> > as you
> > > > > > get in VisualStudio, even get them emailed around... and if you set
> > your
> > > > > > build environment up properly it'll be pretty easy to figure out
> > what any
> > > > > > build-breaking problem is.
> > > > > > * The solution file is just as much a part of the source code as
> > any other
> > > > > > file, and ought to be in source control too. Therefore, yes
> > developers
> > > > > > should be expected to use the same solution file as each other AND
> > the
> > > > > > autobuild. Sure you can change the file for whatever reasons you
> > need
> > > > > > (debugging, moving projects, whatever)... but as with any other
> > file, good
> > > > > > development practice dictates that you never check in any
> > build-breaking
> > > > > > change. If your team all update before committing, then you'll
> > probably find
> > > > > > that collisions are rare, and even then they can be resolved just
> > like a
> > > > > > collision in any other file. And if you find that you are
> > constantly
> > > > > > tripping over each other's solution file changes then frankly it
> > sounds like
> > > > > > your project structure is a mess and you've got bigger problems
> > than just
> > > > > > your build process.
> > > > > > * Regarding unit testing: Our developers hardly ever run unit tests
> > locally,
> > > > > > the build process does it all for them (they're getting lazy!!!).
> > Adding new
> > > > > > unit tests or unit test assemblies also doesn't require changes to
> > your
> > > > > > build config - again if you set it up right, CCNET really can be a
> > low
> > > > > > maintenance 'fire-and-forget' build process. If you are testing
> > internal
> > > > > > methods then it is no longer a unit test - and the majority of TDD
> > > > > > practitioners see it as somewhere between 'a waste of effort' and
> > 'bad
> > > > > > practice'. Even if you must do it, there are still ways of doing it
> > from a
> > > > > > separate assembly ('InternalsVisibleTo' attribute, reflection with
> > > > > > appropriate flags, etc... Google is your friend). And for your
> > sake, I
> > > > > > really hope you are not compiling your unit test code into the same
> > DLLs you
> > > > > > are releasing!
> > > > > > * I've yet to come across any situation where components required
> > for the
> > > > > > deliverable were also required (a) not to be in source control and
> > (b) not
> > > > > > to be available for the developers. API documentation can be built
> > > > > > dynamically. Images can be embedded as resources. Config file can
> > and should
> > > > > > be controlled with good serialization practices. And most other
> > application
> > > > > > 'content' usually winds up coming out of a database of some sort,
> > regardless
> > > > > > of whether its a web app or forms app. Why you would ever want to
> > prevent
> > > > > > your developers from accessing X (where X is an integral part of
> > the
> > > > > > deliverable they are developing) and still expect to include X in
> > the
> > > > > > deliverable and have it function correctly is a mystery. Either you
> > work for
> > > > > > the NSA, or you have some serious trust issues in your workplace...
> > and
> > > > > > given you're coding in .Net, I highly doubt it's the former.
> > > > > > * Obfuscation, encryption, licencing etc. can all be automated if
> > you take
>
> ...
>
> read more »
