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 <[EMAIL PROTECTED]>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: [EMAIL PROTECTED] > > > >
