Update Version Number in a File.

September 23rd, 2009 § 0 comments § permalink

No, not an AssemblyInfo.cs file, that’s really straightforward. C’mon it’s a task that does what it says, easy.

Something I was trying to do is update the version number in, for all simple purposes, a text file – something that’s not xmlpoke-able. So I have the property ready to go and the file I want to update!

My first thoughts were to use the loadfile to get the file into a property and replace it with the version.

<loadfile file=”some.txt” property=”token-file”>



<token key=”VERSION” value=”${version}” />




Awesome, just like the sample and it echos out just fine…so now, how do I save my changes? After some digging around, I looked into the filterchain and read up on the copy task.

Seriously, copying a file now has the ability to modify the internals? Does not compute! Maybe copy, then modify. Anyway, its works now, so I can’t really complain anymore besides the hassle of finding the right task to do the job.

<copy file=”some-template.txt” tofile=”some.txt”>



<token key=”VERSION” value=”${version}” />




Now I know why James keeps telling me to get out of the XML HELL. Coding tasks in XML is just ass backwards.

Automating x86 and x64 Builds.

April 6th, 2009 § 0 comments § permalink

Before attending the ALT.NET Houston Open Spaces Conference, I really didn’t know what to expect besides learning something. What did I want to learn? I had absolutely no idea. I just heard read good things about this event from many others at the Austin and Seattle ones. The sessions I went to were totally great and best of all, I bumped into a few familiar faces I totally didn’t expect to ever see again, hehe.

Now that I have been refreshed with a completely new eagerness to get caught up with the latest and greatest, I’m hoping to be able to contribute at the next ALT.NET conference. Ben, chop-chop, get on it! =)

Here is my main take away from the conference that I just finished.

Starting Point (x86 only): NAnt that kicks off MSBuild, runs tests, and copies to a package folder.

The problem I was running into is that I didn’t fully understand Visual Studio 2008’s Configuration Manager and how to integrate/mimic it with NAnt. I had to set the target platforms x86/x64 and it automatically configured the output paths:

[folder] – [configuration]|[platform]

  • bin/Debug – Debug|Any CPU
  • bin/Release – Release|Any CPU
  • bin/x86/Debug – Debug|x86
  • bin/x86/Release – Release|x86
  • bin/x64/Debug – Debug|x64
  • bin/x64/Release – Release|x64

Remember, these are defaults after you add solution configurations and solution platform. When you build, set the proper targets, F5 and you’re done. As for NAnt, I also had to target the proper configuration/platform:

/p:Configuration=${project.config} /p:Platform=${project.platform}

The tricky part here for me was to get NAnt to find the x64 Framework by parsing out the x86 path and do a string replace. Unfortunately, I’m using 0.85 and it seems to have a bug when trying to pass in a variable as the input string. Currently, I have to specify the directory, UGLY.

<property name=”msbuild-x86″ value=”${framework::get-framework-directory(framework::get-target-framework())}\msbuild.exe” />

<property name=”msbuild-x64″ value=”C:\Windows\Microsoft.NET\Framework64\v3.5\msbuild.exe” />

After reorganizing a few targets and adding more to specify x86 and x64 builds, it worked perfectly. The last step I did was to ensure the builds were targeting separate platform output folders.

Now, my next step is to automate the WiX build…

Visual Studio.NET 2008 + Subversion + NAnt.

February 29th, 2008 § 1 comment § permalink

I’ve had trouble trying to figure out a way to grab the Subversion revision number in order to populate it into the the auto-generated CommonAssemblyInfo.cs file.


Google got me Bryant’s post that linked to Jonathan Malek’s post. Which didn’t help at all because he already migrated his blog to WordPress and the link couldn’t be found. The next link I found worth was Dan Hounshell’s post on the topic. Guess who it refers to? Jonathan’s (now invisible) post.

So finally, I put a few things together and I came up with an almost-done solution, YAY!

<property name=”svnrevision” value=”0″/>
<property name=”svnrevisiontortoise” value=”nothing” />
<if test=”${directory::exists(‘.svn’)}”>

<!–… run the tortoise command line stuff to get latest …–>
<loadfile file=”.svn\all-wcprops” property=”svnrevisiontortoise” failonerror=”false” />
<regex pattern=”ver\/(?’svnrevision’\w+)\/” input=”${svnrevisiontortoise}” failonerror=”false” />

<echo message=”Using Subversion revision number: ${svnrevision}” />

The only stipulation for this is you HAVE to do an update on the repository before calling running this. I tried running a command, but I don’t have Subversion installed on the machine, so it doesn’t recognize it. Plus, I don’t want to add that dependency. Maybe I can throw it in a bin folder or something as a reference.

<exec program=”svn” commandline=”up” failonerror=”true” output=”svn.update.log.txt” append=”true”/>

Now that I have .revision automatically generated, I’ll need to figure out a simple way to both tag and generate the build number.

Where Am I?

You are currently browsing entries tagged with nant at thomas nguyen.