You are viewing a plain text version of this content. The canonical link for it is here.
Posted to nmaven-dev@incubator.apache.org by James Carpenter <jc...@yahoo.com> on 2008/08/09 23:36:30 UTC
Questions regarding current state of C# build systems
============================
Questions:
I could use some advice on the current state of C# build tooling.
* What choices are available and how would you contrast them? I am
currently aware of NAnt, MSBuild and NMaven but have little experience
with any of them, although I am user level expert with Ant and Maven.
Are there any commercial solutions which are currently way ahead of
the above choices?
* Although i am convinced a maven based .NET build will potentially
one day satisfy all my requirements, I don't have a great grasp of the
status quo. Is NMaven in its current state a better solution for a
very large project than other choices?
* If NMaven is currently mature enough to use on a very large project,
what steps should I take to avoid problems? For example I assume I
will need to create an in-house release and drop it into an in-house
repo/repo-proxy such as artifactory.
* Are there any up-to-date articles or other such information covering
these questions? I have taken a look around via google but not found
anything particularly compelling.
It is my hope the sections below will provide some contextual color
and specificity to the above questions.
Thanks in advance for all the time and effort spent responding to this
post.
=============================
Problem Context:
I have very recently joined a newly formed architecture team of a
large (>50 developer) .NET based project. The project has
historically been a huge mess, but new leadership is beginning to
change things for the better. Over the last few months the
organization has started to very successfully apply the scope and
customer management aspects of agile development.
Unfortunately, the code quality aspects of agile development are yet
to be engrained into the company culture. By this I mean test driven
development, automated integration tests, automated performance tests,
continuous integration, and frequent re-factoring as needed. There
appears to be a desire by the business to improve "quality" but little
understanding of what this means and how to achieve it.
To large extent I believe a project delivers on whatever is measured.
I believe much of the necessary quality related cultural change can be
affected by simply deploying good build automation. An important
aspect of this effort is the need for an information radiator which
brings attention and social pressures to bear on the quality aspects.
The information radiator can be as simple as a maker board with a few
simple code metrics for each sub-team alongside a large poster giving
business context to each metric. The metrics on the information
radiator are only intended to apply social/organizational pressures.
With sufficient motivation development teams will naturally take a
closer look at the more detailed quality reports produced by the build
system and other tooling.
=============================
My Background (your audience):
The majority of my expertise is in Java. I have expert user level
knowledge of maven based java builds. I have even written and
enhanced several maven plugins in the past including a few of the very
early (pre-NMaven) C# maven plugins. I am fairly familiar with the C#
core language but not with much of the library and tooling stack
for .NET development.
=============================
Characteristics of Desired Build System
* Sufficiently mature to avoid weeks of custom development and bug
fighting.
* Conducive to modular development.
* Support for completely automated releases (i.e. mvn release:prepare
release:perform)
* Sufficiently easy for junior and intermediate developers to learn
and use from a surface user perspective.
* Supports the evil that is clear case. (Should also support the
goodness that is SVN in the event my team is able to affect such a
change.)
* Produces test coverage, code complexity, and other such quality
reports.
* Easily driven by an appropriate continuous integration solution.
(Probably TeamCity)
=============================
Example Solution for Java based Code
* SVN for source control
* maven based build with properly configured release, and site plugins
* artifactory or similar for repo proxy
* TeamCity for CI. (CruiseControl, Hudson, etc. are great but not as
nice as TeamCity. The distributed builds and remote build
functionality are sadly unmatched by an OS solution.)
* Configure CI to send out emails on build critical failures.
* properly configured cobertura and/or clover plugin.
* various other quality metric report plugins (Checkstyle, PMD,
FindBugs, JDepend, etc.)
* Sonar (maybe XRadar)
* Large wall monitor(s) displaying results of Sonar overview page.
* Large poster beside wall mounted monitors giving business context to
each high level metric.
* Lots of mentoring and evangelizing to help influence the culture in
a positive direction.
Note: Sonar and wall monitors can be replaced with a frequently
updated marker board.
With experience all of the technical aspects can be put in place with
only a few days of work. The most time consuming part is actually
working out the dependencies section of the pom files for code with
lots of jars of unknown versions.
==============================
Thanks again for all your time and effort spent reading and responding
to this post.
Sincerely,
James Carpenter
cell: 832-677-7247
email: jcarpenter621@yahoo.com
Re: Questions regarding current state of C# build systems
Posted by Shane Isbell <sh...@gmail.com>.
Hi James,
You might also want to check out http://www.codeplex.com/byldan. It's a
Mavenish build system written in C# and is pretty fast. It's a project that
I started a while ago, but I haven't done any work on it within the last
year. It does the basics of compiling and testing with metadata and allows
writing of plugins. There are still a lot of missing components, but it may
be worth a look.
Shane
On Sat, Aug 9, 2008 at 4:36 PM, James Carpenter <jc...@yahoo.com>wrote:
> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them? I am
> currently aware of NAnt, MSBuild and NMaven but have little experience with
> any of them, although I am user level expert with Ant and Maven. Are there
> any commercial solutions which are currently way ahead of the above choices?
>
> * Although i am convinced a maven based .NET build will potentially one day
> satisfy all my requirements, I don't have a great grasp of the status quo.
> Is NMaven in its current state a better solution for a very large project
> than other choices?
>
> * If NMaven is currently mature enough to use on a very large project, what
> steps should I take to avoid problems? For example I assume I will need to
> create an in-house release and drop it into an in-house repo/repo-proxy such
> as artifactory.
>
> * Are there any up-to-date articles or other such information covering
> these questions? I have taken a look around via google but not found
> anything particularly compelling.
>
> It is my hope the sections below will provide some contextual color and
> specificity to the above questions.
>
> Thanks in advance for all the time and effort spent responding to this
> post.
>
> =============================
> Problem Context:
>
> I have very recently joined a newly formed architecture team of a large
> (>50 developer) .NET based project. The project has historically been a
> huge mess, but new leadership is beginning to change things for the better.
> Over the last few months the organization has started to very successfully
> apply the scope and customer management aspects of agile development.
>
> Unfortunately, the code quality aspects of agile development are yet to be
> engrained into the company culture. By this I mean test driven development,
> automated integration tests, automated performance tests, continuous
> integration, and frequent re-factoring as needed. There appears to be a
> desire by the business to improve "quality" but little understanding of what
> this means and how to achieve it.
>
> To large extent I believe a project delivers on whatever is measured. I
> believe much of the necessary quality related cultural change can be
> affected by simply deploying good build automation. An important aspect of
> this effort is the need for an information radiator which brings attention
> and social pressures to bear on the quality aspects. The information
> radiator can be as simple as a maker board with a few simple code metrics
> for each sub-team alongside a large poster giving business context to each
> metric. The metrics on the information radiator are only intended to apply
> social/organizational pressures. With sufficient motivation development
> teams will naturally take a closer look at the more detailed quality reports
> produced by the build system and other tooling.
> =============================
> My Background (your audience):
>
> The majority of my expertise is in Java. I have expert user level
> knowledge of maven based java builds. I have even written and enhanced
> several maven plugins in the past including a few of the very early
> (pre-NMaven) C# maven plugins. I am fairly familiar with the C# core
> language but not with much of the library and tooling stack for .NET
> development.
>
> =============================
> Characteristics of Desired Build System
>
> * Sufficiently mature to avoid weeks of custom development and bug
> fighting.
> * Conducive to modular development.
> * Support for completely automated releases (i.e. mvn release:prepare
> release:perform)
> * Sufficiently easy for junior and intermediate developers to learn and use
> from a surface user perspective.
> * Supports the evil that is clear case. (Should also support the goodness
> that is SVN in the event my team is able to affect such a change.)
> * Produces test coverage, code complexity, and other such quality reports.
> * Easily driven by an appropriate continuous integration solution.
> (Probably TeamCity)
>
> =============================
> Example Solution for Java based Code
>
> * SVN for source control
> * maven based build with properly configured release, and site plugins
> * artifactory or similar for repo proxy
> * TeamCity for CI. (CruiseControl, Hudson, etc. are great but not as nice
> as TeamCity. The distributed builds and remote build functionality are
> sadly unmatched by an OS solution.)
> * Configure CI to send out emails on build critical failures.
> * properly configured cobertura and/or clover plugin.
> * various other quality metric report plugins (Checkstyle, PMD, FindBugs,
> JDepend, etc.)
> * Sonar (maybe XRadar)
> * Large wall monitor(s) displaying results of Sonar overview page.
> * Large poster beside wall mounted monitors giving business context to each
> high level metric.
> * Lots of mentoring and evangelizing to help influence the culture in a
> positive direction.
>
> Note: Sonar and wall monitors can be replaced with a frequently updated
> marker board.
>
> With experience all of the technical aspects can be put in place with only
> a few days of work. The most time consuming part is actually working out
> the dependencies section of the pom files for code with lots of jars of
> unknown versions.
> ==============================
>
> Thanks again for all your time and effort spent reading and responding to
> this post.
>
> Sincerely,
> James Carpenter
> cell: 832-677-7247
> email: jcarpenter621@yahoo.com
>
>
>
>
Re: Questions regarding current state of C# build systems
Posted by James Carpenter <jc...@yahoo.com>.
I still havn't hit the problem with the level of agression I would like to be able to devote to the effort. Surface evaluations appear to bear out my initial concerns that nothing is truely capable of everything I need without significant development effort.
NMaven:
1) Best long term choice available.
From past experience a couple years ago building C# with pre-NMaven .NET sandbox plugins as well as past discussions on this mailing list the ability for the repository to store assemblies without requiring versions in the file names (and assembly meta-data) is absolutely critical.
--- On Tue, 9/2/08, Brett Porter <br...@apache.org> wrote:
From: Brett Porter <br...@apache.org>
Subject: Re: Questions regarding current state of C# build systems
To: nmaven-dev@incubator.apache.org
Date: Tuesday, September 2, 2008, 2:36 AM
Hi James,
Sorry it has taken quite a while to reply, I've been behind on mail.
You may have already made a decision, but it'd be great to hear what
you found out.
Thoughts inline...
On 10/08/2008, at 9:36 AM, James Carpenter wrote:
> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them? I am
> currently aware of NAnt, MSBuild and NMaven but have little
> experience with any of them, although I am user level expert with
> Ant and Maven. Are there any commercial solutions which are
> currently way ahead of the above choices?
I'm not aware of any other commercial solutions to this specific area
myself. MSBuild is completely integrated with visual studio which is
of benefit, though the available tasks I have found for it for the
tools you refer to are limited.
NAnt certainly has been around longer than NMaven and so is more
mature and has more resources available for it. However, I believe
NMaven is the closest to what you are ultimately looking for: being
based on Maven you will already have the ability to run the tools
you've described and use it from within any continuous integration
server, and this is certainly where its objectives lay.
> * Although i am convinced a maven based .NET build will potentially
> one day satisfy all my requirements, I don't have a great grasp of
> the status quo. Is NMaven in its current state a better solution
> for a very large project than other choices?
I believe NMaven would be technically capable of meeting your needs
for a large project, but there are a couple of caveats.
Between the stage of the project and the fact that it is incubating,
it is essential to become involved in the community in some way to get
the most out of it. I'd say if you have some time to put in here it
will be repaid, but it does still require that investment at the moment.
We currently only have one official release - 0.15. While this is much
more suitable for some of your applications (since it is much more
closely aligned to Maven's practices), it also lacks a lot of the
features that are present in 0.14-SNAPSHOT. While we're working on
(and looking for volunteers) to get involved in migrating that to the
trunk now, using it now requires building an inhouse release and being
involved here as you mentioned in a later question.
I hope that helps clear it up.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Questions regarding current state of C# build systems
Posted by James Carpenter <jc...@yahoo.com>.
I still havn't hit the problem with the level of agression I would like to be able to devote to the effort. Surface evaluations appear to bear out my initial concerns that nothing is truely capable of everything I need without significant development effort.
NMaven:
1) Best long term choice available.
From past experience a couple years ago building C# with pre-NMaven .NET sandbox plugins as well as past discussions on this mailing list the ability for the repository to store assemblies without requiring versions in the file names (and assembly meta-data) is absolutely critical.
--- On Tue, 9/2/08, Brett Porter <br...@apache.org> wrote:
From: Brett Porter <br...@apache.org>
Subject: Re: Questions regarding current state of C# build systems
To: nmaven-dev@incubator.apache.org
Date: Tuesday, September 2, 2008, 2:36 AM
Hi James,
Sorry it has taken quite a while to reply, I've been behind on mail.
You may have already made a decision, but it'd be great to hear what
you found out.
Thoughts inline...
On 10/08/2008, at 9:36 AM, James Carpenter wrote:
> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them? I am
> currently aware of NAnt, MSBuild and NMaven but have little
> experience with any of them, although I am user level expert with
> Ant and Maven. Are there any commercial solutions which are
> currently way ahead of the above choices?
I'm not aware of any other commercial solutions to this specific area
myself. MSBuild is completely integrated with visual studio which is
of benefit, though the available tasks I have found for it for the
tools you refer to are limited.
NAnt certainly has been around longer than NMaven and so is more
mature and has more resources available for it. However, I believe
NMaven is the closest to what you are ultimately looking for: being
based on Maven you will already have the ability to run the tools
you've described and use it from within any continuous integration
server, and this is certainly where its objectives lay.
> * Although i am convinced a maven based .NET build will potentially
> one day satisfy all my requirements, I don't have a great grasp of
> the status quo. Is NMaven in its current state a better solution
> for a very large project than other choices?
I believe NMaven would be technically capable of meeting your needs
for a large project, but there are a couple of caveats.
Between the stage of the project and the fact that it is incubating,
it is essential to become involved in the community in some way to get
the most out of it. I'd say if you have some time to put in here it
will be repaid, but it does still require that investment at the moment.
We currently only have one official release - 0.15. While this is much
more suitable for some of your applications (since it is much more
closely aligned to Maven's practices), it also lacks a lot of the
features that are present in 0.14-SNAPSHOT. While we're working on
(and looking for volunteers) to get involved in migrating that to the
trunk now, using it now requires building an inhouse release and being
involved here as you mentioned in a later question.
I hope that helps clear it up.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/
Re: Questions regarding current state of C# build systems
Posted by Brett Porter <br...@apache.org>.
Hi James,
Sorry it has taken quite a while to reply, I've been behind on mail.
You may have already made a decision, but it'd be great to hear what
you found out.
Thoughts inline...
On 10/08/2008, at 9:36 AM, James Carpenter wrote:
> ============================
> Questions:
>
> I could use some advice on the current state of C# build tooling.
>
> * What choices are available and how would you contrast them? I am
> currently aware of NAnt, MSBuild and NMaven but have little
> experience with any of them, although I am user level expert with
> Ant and Maven. Are there any commercial solutions which are
> currently way ahead of the above choices?
I'm not aware of any other commercial solutions to this specific area
myself. MSBuild is completely integrated with visual studio which is
of benefit, though the available tasks I have found for it for the
tools you refer to are limited.
NAnt certainly has been around longer than NMaven and so is more
mature and has more resources available for it. However, I believe
NMaven is the closest to what you are ultimately looking for: being
based on Maven you will already have the ability to run the tools
you've described and use it from within any continuous integration
server, and this is certainly where its objectives lay.
> * Although i am convinced a maven based .NET build will potentially
> one day satisfy all my requirements, I don't have a great grasp of
> the status quo. Is NMaven in its current state a better solution
> for a very large project than other choices?
I believe NMaven would be technically capable of meeting your needs
for a large project, but there are a couple of caveats.
Between the stage of the project and the fact that it is incubating,
it is essential to become involved in the community in some way to get
the most out of it. I'd say if you have some time to put in here it
will be repaid, but it does still require that investment at the moment.
We currently only have one official release - 0.15. While this is much
more suitable for some of your applications (since it is much more
closely aligned to Maven's practices), it also lacks a lot of the
features that are present in 0.14-SNAPSHOT. While we're working on
(and looking for volunteers) to get involved in migrating that to the
trunk now, using it now requires building an inhouse release and being
involved here as you mentioned in a later question.
I hope that helps clear it up.
Cheers,
Brett
--
Brett Porter
brett@apache.org
http://blogs.exist.com/bporter/