[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: C# AssemblyInfo integration

From: Bryant Eastham <beastham_at_pewla.us.pewg.panasonic.com>
Date: Thu, 27 Aug 2009 09:11:37 -0600

Yves Goergen [mailto:nospam.list_at_unclassified.de] wrote:

> Okay. This is Linux. I'm sure its totally easy on Linux. But I'm
> not using Linux for this but Windows and Visual Studio 2008...

> And the solutions I've seen on the web look like - excuse me - a hack.

We used to do something similar to what you are proposing. It didn't work. One thing that people do not consider when discussing the use of the SVN revision is the scale of the number over time - we abandoned it because we would soon approach a time where it *could not be used* in AssemblyInfo or Manifest files.

There were also political reasons, as the use of such a large number in a version was misunderstood by some as a bad thing.

We also abandoned the use of "make" to do the work, as it was (I agree) a hack. Instead we use autoconf/configure. Given cygwin, our solution is cross platform (currently used on Win32, Win64, various Linux, BSD, Solaris).

The problem of modifying versioned files is resolved by autoconf's use of template files (which are not modified).

The only downside is that to update the information you have to run configure. However, since it is primarily important when used by our build system the fact that it has that as part of its process is not a big deal.

We also extract more information about the Subversion working copy. As you must realize, the SVN revision is not enough to determine what code was used.

For this purpose, one of our RELEASE.txt files shows the following [somewhat redacted]:

Version 5.0 Build 752
(26 Aug 2009, from /branches/typedefs/src/java (r22675) on svn+ssh://host/repo)

The version field comes from configure.ac (standard usage).
The build is an argument to configure, which our build system uses.
The branch is from the working copy at the time of configure.
The revision and repository are also from the working copy at configure.

In our system, a "make dist-src" creates an ".svn-cache" file which configure uses to obtain the same information if not run from inside a working copy (which it would not be if unzipped/untarred).

Here is an example of a Java manifest file [again, redacted and with lines removed]:

Specification-Version: 5.0
Build-Date: 26 Aug 2009

And directly related to your question, here is the line from one of our AssemblyInfo.cs.in files:

[assembly: AssemblyVersion("@SRC_BUILD_DOTTED@")]

Which would become:

[assembly: AssemblyVersion("")]

To summarize, our belief is to use the right tool for the right job. Version control systems are not build systems. Artifact versioning is a separate problem from reproducibility/description and the two should not be coupled too closely. Configure is *much* better at textual substitution than a bunch of hacked make rules.

One issue that we have had is that our developers want to just "svn co and build (using their IDE)". This is not possible using our system, as they must run configure (at least once per working directory) in order for the correct files to exist. However, it is not critical that the information on the developer machines be current (unless you plan on distributing it, and *nobody* should ever do that). They typically run configure once, and then just use their IDE normally.

If people are interested in the specifics of this solution, I'd be happy to share. We don't have a "public face", so there isn't an easy place for me to post files. I'd be happy to provide the information, however.

Bryant Eastham
Chief Architect

Panasonic Electric Works Laboratory of America - SLC Lab
4525 So. Wasatch Blvd., Suite 100, 84124
Salt Lake City, UT 84124

T 801.993.7124
F 801.993.7260


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-08-27 17:12:54 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.