YUI compressor and TFS Build

Question

We have a project where the .js and .css files gets compressed with YUI Compressor. A very good tool. We also use TFS 2010 as a build server with nightly builds that also deploys to our dev web site.

The problem we're having is that the file YUI generates causes a "Access denied"-problem. This is because there already is such a file generated from before, and that it's a part of the project, making it read-only. We can however remove it from the project and it should create fine. The problem then is that the generated file doesnt get included in the actual deploy package.

Locally i have no problem because i have a pre build event command script, which deletes the existing files. This apparently doesnt work on the build server. Maybe the tfs context user lacks permission, i dont know.

Is there anyone who might have had similiar problems?

Update 21/11: The question may be abit vague. To simplify, lets just say i want this to work as it does locally:

IF NOT $(ConfigurationName) == DEBUG DEL "$(ProjectDir)Styles\styles.min.css
IF NOT $(ConfigurationName) == DEBUG DEL "$(ProjectDir)JavaScript\script.min.js

This is defined in the pre-build command event line, under Project properties -> Build events.

The script removes the files before the YUI-file generation, and thus there is no file to overwrite. Could it be that simple that the user context that executes the TFS-build have insufficent modify rights?

SOLUTION:

We ended up with the following code in the pre-build event:

attrib -r "$(ProjectDir)Styles\styles.min.css"
attrib -r "$(ProjectDir)JavaScript\script.min.js"
IF NOT $(ConfigurationName) == Debug $(MSBuildBinPath)\msbuild.exe "$(ProjectDir)Config\MSBuild\BuildSettings.xml"

/Mattias

Answer 1

If the files are part of your project and downloaded from the TFS repository, first always remove te read-only flag if your need to do any processing on them, for example deletion. So in your script, first do:

attrib -r *.js
attrib -r *.css

Should be able to delete them fine after that. It is probably not a permission issue, since the account that is used to download the files is also the account used to delete them.