Re: Questions regarding current state of C# build systems
I posted a question on the maven developers mailing list on how to best support repository artifacts which are sensitive to changes in their filenames (read .NET assemblies). I have gotten a very interesting response from Oleg Gusakov regarding some work he is doing with Mercury. If Oleg implements the slight tweak I suggested (or some evolution of it), it is very likely Oleg will have done all the heavy lifting necessary to make proper storage of dlls trivial.
The thread subject is: Requesting advice on how to best extend the maven repository format
From: James Carpenter <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email] Date: Wednesday, September 3, 2008, 6:14 PM
In general I believe its very important to support 3rd party assemblies without
requiring re-compilation. Due to the meta-data contained within an assembly
and/or the digital signatures invvoled renaming an assembly is simply not an
option. I suppose it's ok to store assemblies in the repository in some
archive format which includes a version in the file name, but all this needs to
be undone by the time the compiler and/or CLR see them.
On a related note, the pdb files and archives of the source associated with an
assembly should also be stored in the repository. The necessary magic to have
the repository treated as a symbol server and source server will also need to be
Without addressing this issue, I simply don't see how NMaven will ever
achieve broad acceptance and usage. As you will notice from my earlier
comments, for me this is an absolute show-stopper. Some of the libraries I
need to reference are indeed closed source and/or delivered by other teams
within the company which manage their builds differently than mine.
I appreciate all the hard work and effort the core NMaven developers have
done. The level effort involved is not something I am personally willing to
commit to the NMaven project, so I feel a litle bad complaining.
--- On Wed, 9/3/08, Shane Isbell <[hidden email]> wrote:
From: Shane Isbell <[hidden email]>
Subject: Re: Questions regarding current state of C# build systems
To: [hidden email] Date: Wednesday, September 3, 2008, 5:50 PM
I did a 180 (a long and winding 180), finally coming to the conclusion that
not having versions in the filename doesn't buy us all that much, at least
in open development environments.
My preference is that all .NET artifacts going into public repository should
be signed with a strong name. If this is the case, it doesn't really matter
whether an artifact is compiled with the version in the filename or not.
0.16 does support using of system scope for referencing an assembly locally
on the file system so that assemblies external to Maven can still be used.
> On 04/09/2008, at 1:32 AM, James Carpenter wrote:
> Where do I find the "long and winding discussions about the
>> format"? Is there a mailing list thread(s) on the maven dev list
> Sorry, that's what I was referring to - it has come up a few times,
> don't think it has ever been summarised in one place. I don't have
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.
On Sat, Aug 9, 2008 at 4:36 PM, James Carpenter <[hidden email]>wrote:
> 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
> 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
> Characteristics of Desired Build System
> * Sufficiently mature to avoid weeks of custom development and bug
> * Conducive to modular development.
> * Support for completely automated releases (i.e. mvn release:prepare
> * 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.
> James Carpenter
> cell: 832-677-7247
> email: [hidden email] >