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
> 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
The version field comes from configure.ac (standard usage).
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
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("5.0.0.752")]
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
Panasonic Electric Works Laboratory of America - SLC Lab
T 801.993.7124
------------------------------------------------------
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
|
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.