views:

133

answers:

2

The Scenario
My project has a post-build phase set up to run a batch file, which reads a text file "version.txt". The batch file uses the information in version.txt to inject the DLL with a version block using this tool.

The version.txt is included in my project to make it easy to modify. It looks a bit like this:

@set #Description="TankFace Utility Library"
@set #FileVersion="0.1.2.0"
@set #Comments=""

Basically the batch file renames this file to version.bat, calls it, then renames it back to version.txt afterwards.

The Problem
When I modify version.txt (e.g. to increment the file version), and then press F7, the build is not seen as out-of-date, so the post-build step is not executed, so the DLL's version doesn't get updated.

I really want to include the .txt file as an input to the build, but without anything actually trying to use it.

If I #include the .txt file from a CPP file in the project, the compiler fails because it obviously doesn't understand what "@set" means.

If I add /* ... */ comments around the @set commands, then the batch file has some syntax errors but eventually succeeds. But this is a poor solution I think.

So... how would you do it?

A: 

This may be too "hacky" but this might work:

  1. Write a quick Perl (etc.) script to check version.txt has been updated.
  2. If the file has been modified, have this script update a dummy source file that is compiled with your project.
  3. Run the script as a pre-build event.

This way if the script sees that the file has changed, it will change the other one, which will force a re-build.

Hacky, but try it if you're scraping the bottom of the barrel.

John at CashCommons
Yep definitely hacky. I don't fancy having to work out whether the file has been modified, I'd have to store the last used filetime or something... but good work for thinking outside the box :)
demoncodemonkey
+1  A: 

This works in VS2005. If you're not using that, some of the settings may be in different places or with different names.

Add the text file to your project, right click on it in the Solution Explorer and select 'Properties'. Under Configuration Properties > General make sure that the file is not excluded from the build. Under Custom Build Step > General, put your existing post-build command as the Command Line setting. Make sure you specify your .txt file as the output file. Now F7 should spot changes to the text file and run your batch file.

Charles Anderson
This forced the batch file to be run every time I press F7, regardless of whether the version.txt file has been modified. This slows down my build, enough that I notice it. Do you know how I can only run the custom build step when version.txt has been modified?
demoncodemonkey
Hmm, same for me. Sorry about that. I was able to fix it, though, by specifying the .txt file as the output file. Try that?
Charles Anderson
OK I've added the .txt file to the Outputs of the custom build step. But now whenever I press F7 it runs the build step, then modifies the timestamp of the .txt file, causing it to run the build step every time. I'm sure I'm missing something obvious here... it can't be this difficult surely?!
demoncodemonkey
Sounds like Visual Studio is now working the way you want it, but your batch file is causing the text file to be modified, so VS thinks it's immediately out of date again. Could you alter the batch file to copy the text file into version.bat, and then delete this copy at the end? That way version.txt itself won't be affected.
Charles Anderson
+1 because this is the path you want to be on, even if it isn't all the way to where you want it to be yet. I'd second the idea of copying version.txt to a temporary .bat that is deleted after use. Changing any attributes of a source file in a build step is risky and likely to cause some kind of confusion. Source files for each step should be treated as read-only by that step. Even if they are created by other steps.
RBerteig