visual c++ 2008 keeps losing custom build rule setting

Question

So for various "boring" reasons, I'm stuck using VC++ 2008.

Now, I have a custom build rule that parses a ".h" file and produces a .cpp.

The build rule works fine when I can get the setting in the .vcproj (it appears as a <Tool Name="my rule"/> element as a child of the <FileConfiguration> elements for each <File> element).

In the ".rule" file, the FileExtension attribute I've specified is "*.hxx" and not "*.h" as I don't want the custom rule running on every .h, only the ones I want it to. Changing the extension of the files to run the rule on to something other than .h is not an option for reasons that are beyond my control.

The rule works fine, the generated .cpp gets compiled, the dependencies etc are all working - i.e. VC++ only does the custom step when the .h changes etc.

Manually hacking the xml in the .vcproj gets thing working, the issue is the Visual Studio GUI keeps messing with the tool setting and deleting it from the ".vcproj". I haven't definitively determined exactly under what conditions Visual Studio mucks up the setting, as it's somewhat random, but mostly when any change to the project needs to be saved is my observation.

Sometimes (not always) I can manually change the tool in the properties page in the visual studio GUI and it will save it for the active configuration (e.g. "Debug"), but when I try to add it to other configurations (e.g. "Release" or "All configurations") the GUI gets confused and deletes the tool setting for all configurations instead of adding it for the other configuration.

This seems to happen also if I first change the active configuration -> when you go to set the custom tool it gets confused and deletes the setting from all configurations.

I've been able to get similar rules working fine when the input file for the custom rule has a unique extension, it seems to be related to the input name matching ".h" and the default rule for .h's and that my ".rule" file doesn't specify a corresponding matching pattern.

Note this setup with the non matching FileExtension pattern is what was recommended on MSDN for VC++ 2008, which is why I did it that way.

Anybody had any similar issues ? Any clues at all on what a robust solution and/or workaround might be ?

I just need to preserve the setting in the context that NOOBS might be using the VS GUI so you can't trust them to not do "certain things".

Answer 1

OK, so after much searching here, and anywhere else I could think of, and trying a bunch of dastardly incantations I've still got no joy on an actual solution to the problem of preventing the IDE deleting the custom build tool setting when the extension pattern doesn't match the file.

So the work around was I changed the rule to use "*.h" pattern and do a test to see if the custom command needs to be run. The following is my "FunkyRule.rules" file in case anybody needs to see what I did:

<?xml version="1.0" encoding="utf-8"?>
<VisualStudioToolFile
   Name="Funky code generator"
   Version="8.00"
   >
   <Rules>
      <CustomBuildRule
          Name="Funky"
          DisplayName="Funky code generator"
          CommandLine="IF NOT EXIST $(InputFileName) goto :notFound &#x0D;&#x0A;
                       NeedsFunky $(InputFileName) 1>nul || goto :notFound &#x0D;&#x0A;
                       echo Generating Funky things for $(InputFileName) &#x0D;&#x0A;
                       FunkyCodeGenerator $(InputFileName) -o &quot;.\GeneratedFiles\funky_$(InputName).cpp &quot;&#x0D;&#x0A;
                       goto :done &#x0D;&#x0A;
                       :notFound &#x0D;&#x0A;
                       exit 0 &#x0D;&#x0A;
                       :done &#x0D;&#x0A;"
          Outputs=".\GeneratedFiles\funky_$(InputName).cpp"
          AdditionalDependencies="$(InputFileName)"
          FileExtensions="*.h"
          ShowOnlyRuleProperties="false"
          >
          <Properties>
          </Properties>
       </CustomBuildRule>
   </Rules>
</VisualStudioToolFile>

This CustomBuildRule needs two external commands "NeedsFunky" and "FunkyCodeGenerator". "NeedsFunky" is a command that returns 0 if the input .h is a valid input for "FunkyCodeGenerator" and non-zero otherwise. "FunkyCodeGenerator" is the command that does the "funky-ness" taking the input .h as a parameter and requiring a -o option to specify the output file. In this context (i.e. whatever environmemt Visual Studio calls the resulting temporary .bat file), I had some trouble making an IF statement work using the usual "IF errorlevel" syntax, so hence the unusual "cmd || goto :failLabel" construct.

If you add this rules file to the custom build rules for a project you'll automatically get "some funkiness" on all your ".h" files :-)