Prebuild event works in Windows 7, fails in XP
I have a pre build event set up to generate the version/build number to embed in my exe. The event consists of a call to a batch file that does the actual work (a parameter is passed to the batch file). The batch file works as it should on all of the computers I've tried it on, including the Windows XP 开发者_Python百科computers. It also runs fine as a pre build event on the 3 computers here running windows 7. The pre build event fails, however, on Windows XP. Delphi returns an error code that I can't seem to find a reference to anywhere, "20018".
I've tried a number variations to the way I call the batch file without any luck. Does anyone have an idea what's happening?
The build event is as follows:
call "..\..\Build Tools\PreBuild.bat" "$(PROJECTDIR)"
UPDATE: I've removed the source of the batch file, since it had no relevance for the actual problem.
You gave so little information that I am tempted to vote to close. Instead I will venture a wild guess. You should post the commands in your post-build step.
If you don't know which line is failing, try the first one alone, and remove the rest, and see if that passes.
For example, I often have problems on XP machines using XCOPY commands in post-build steps, and these commands often result in really odd error codes that I am unable to diagnose or determine the meaning of. So if you have an XCOPY command, you should try the XCOPY inside and outside the build environment, and see if it works on that Windows XP box, for example.
You can copy the commands, as they are run, in their macros-expanded form, from the "Output" tab in the Rad Studio IDE, paste them into notepad, run them as a batch file, and try to figure out why they don't work on windows XP.
Here's an example of a workaround, using XCOPY. If this fails on XP, I tweak it till it works:
XCOPY SourceDir DestDir
I have had to fix it this way:
XCOPY.exe SourceDir DestDir
In another case, I found that I had to fix it this way:
call XCOPY SourceDir DestDir
You ALSO mention you are simply running a mysterious batch file and you fail to mention what it does. So let's see, what we could do differently to run a batch file from a post build step.... When I run a batch file like this, I sometimes have problems on XP, like this:
batchfilename.cmd
But when I run it differently, I find it worked on XP, but I lose the command line output:
call batchfilename.cmd
It seemed that something strange was happening when running post-build steps in the IDE, that could be resolved by trying the commands outside the IDE, in various forms.
The number (20018) you mention is a bit of a silly thing to go googling, it's probably the ERRORLEVEL (return value to the command shell) of whatever tool you are running in your batch file. Since you told us nothing about what tools you're running, I wonder if you have even done the basic step of looking at what happens when you run that batch file OUTSIDE the IDE on that XP machine. My guess is that if it didn't come from your own batch file, that it came from deep in the guts of MSBUILD itself, which is something that very few Delphi people will know the source code to (even the Delphi team itself is using a binary from Microsoft to provide MSBUild functionality). I notice that MSBUILD's built in tasks for doing post-build and pre-build steps are an area of the IDE that need improvement, especially when it comes to debugging problems like this. You can however, simply run them outside the IDE and see if they work that way, and you can try stuff, as I have suggested above.
If this is your batch file ... I suggest that due to dependency issues, you might not want to use such a batch file technique to modify an RC file, as it might expose some strange dependency issues in MSBUILD with RAD/Delphi build tasks. I have also seen some weird BRCC32 failures, on XP that I have not been able to reproduce.
Ok, I finally found the answer here: http://delphi.about.com/od/devutilities/a/pre_post_build.htm
The problem was spaces in the path to the batch file being called. Apparently this isn't a problem in Windows 7.
Removing the space in the build tools directory and changing the pre build event to the following fixed the problem:
call ..\..\BuildTools\PreBuild.bat "$(PROJECTDIR)"
Here's the important bit from the link:
Command Line: This is the trickiest of them all, but after you get one working, they’re all easy. The trick here is not to use quotes on the program’s name but instead use the windows SFN (Short File Name). The reason is that, should you need to use quotes to enclose the path of your file, the IDE gets confused with too many quotes. So, these are the wrong ways of adding that command line above:
C:\Program Files\SoftwarePassport\Armadillo.exe D:\Dev\My Prog\Prot.arm /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" D:\Dev\My Prog\Prot.arm /P
C:\Program Files\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
"C:\Program Files\SoftwarePassport\Armadillo.exe" "D:\Dev\My Prog\Prot.arm" /P
This last one should work, if it were not for the IDE to be confused with it. So, what does work is either of these: C:\Progra~1\Softwa~1\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
C:\Progra~1\SoftwarePassport\Armadillo.exe "D:\Dev\My Prog\Prot.arm" /P
精彩评论