Is MSbuild appropriate for automated builds of a large code base?

[jrett]

I've got a source tree with over 100 projects, some depending on others and
I'd like to set this up on an automated nightly build, or where devs can do
private builds of the entire source tree to verify their code integration
into the build before they check in.
When I worked at Microsoft, we used CoreXt to do this. Does MSBuild support
this sort of build management? Or should I look elsewhere like NAnt.

--
Jaan

[Barry Kelly]

jrett <jr***@discussions.microsoft.comwrote:

I've got a source tree with over 100 projects, some depending on others and
I'd like to set this up on an automated nightly build, or where devs can do
private builds of the entire source tree to verify their code integration
into the build before they check in.
When I worked at Microsoft, we used CoreXt to do this. Does MSBuild support
this sort of build management? Or should I look elsewhere like NAnt.

It can work like that, yes. MSBuild is a task in itself, so it can
recurse; and as we all know, recursion is divine etc. etc. for solving
the big problems.

I prefer MSBuild's approach to Ant - with Ant, one must write the rules
to infer the output files, whereas with MSBuild one can create inference
rules through pattern matching etc.

It's still not quite as flexible as GNU Make 3.80 + Cygwin out of the
box, though.

However, the fact that VS solutions and projects are automatically
understood by MSBuild goes a long way towards automating much drudgery,
so I'm pretty happy.

-- Barry

--
http://barrkel.blogspot.com/

[jrett]

Thanks for the reply. That is a good answer. I do still have another road
block. All our code is in .NET 1.1. When should I expect a version MSBuild
to come out that doesn't require a patch or a hack to get it to build .NET
1.1 or any other code types like C/C++. The MSBee feels like a hack.
--
Jaan
"Barry Kelly" wrote:

jrett <jr***@discussions.microsoft.comwrote:

I've got a source tree with over 100 projects, some depending on others and
I'd like to set this up on an automated nightly build, or where devs can do
private builds of the entire source tree to verify their code integration
into the build before they check in.
When I worked at Microsoft, we used CoreXt to do this. Does MSBuild support
this sort of build management? Or should I look elsewhere like NAnt.

It can work like that, yes. MSBuild is a task in itself, so it can
recurse; and as we all know, recursion is divine etc. etc. for solving
the big problems.

I prefer MSBuild's approach to Ant - with Ant, one must write the rules
to infer the output files, whereas with MSBuild one can create inference
rules through pattern matching etc.

It's still not quite as flexible as GNU Make 3.80 + Cygwin out of the
box, though.

However, the fact that VS solutions and projects are automatically
understood by MSBuild goes a long way towards automating much drudgery,
so I'm pretty happy.

-- Barry

--
http://barrkel.blogspot.com/

[jrett]

When using msbuild in this recursive manner, can the build order be
controlled such the dependencies get build in the correct order?
What is the best practice for automated building of a large number of
projects. Is it recommended that they all be put into a 'solution' file or
should they be processed in this recursive manner?

Thanks for your previous reply.
--
Jaan
"Barry Kelly" wrote:

jrett <jr***@discussions.microsoft.comwrote:

I've got a source tree with over 100 projects, some depending on others and
I'd like to set this up on an automated nightly build, or where devs can do
private builds of the entire source tree to verify their code integration
into the build before they check in.
When I worked at Microsoft, we used CoreXt to do this. Does MSBuild support
this sort of build management? Or should I look elsewhere like NAnt.

It can work like that, yes. MSBuild is a task in itself, so it can
recurse; and as we all know, recursion is divine etc. etc. for solving
the big problems.

I prefer MSBuild's approach to Ant - with Ant, one must write the rules
to infer the output files, whereas with MSBuild one can create inference
rules through pattern matching etc.

It's still not quite as flexible as GNU Make 3.80 + Cygwin out of the
box, though.

However, the fact that VS solutions and projects are automatically
understood by MSBuild goes a long way towards automating much drudgery,
so I'm pretty happy.

-- Barry

--
http://barrkel.blogspot.com/