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
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.
Related
I have a project that need to run in a pen drive, the content is updated daily, and i need a automated way to generate a single file (.exe) to be downloaded by users.
I use this tool https://github.com/mllrsohn/node-webkit-builder, but when build for windows, the build generate multiple files ( dlls, dat ,exe ).
This break my automation because the content need to be downloaded (single file).
Any help?
As far as I know, it can't. You could try making a 7zip SFX archive and running your own program instead of an installer.
This needs to create temporal files when run (which are deleted when the program quits) and I don't think you can remove the initial prompt. If you're okay with that, it might be what you need.
Edit: You can get the necessary SFX modules here.
I want to change the build dir of team city build agent to:
E://MY_PROJECT_SVN
While installing the build agent I set the same but it diaplays C://buildAgent/work in TeamCity web ui due to which my build fails.
My buildAgent.properties file shows
workDir=E\:\\MY_PROJECT_SVN
And buildAgent.dist.properties file shows
workDir=E://MY_PROJECT_SVN
But I get following error when I run team city
Failed to start MSBuild.exe. Failed to find project file at path:
C:\BuildAgent\work\3ac16e0b4e3af05b\Modules\SIM5.sln
Because of wrong working dir
The buildAgent.dist.properties is indeed just an example, but the solution is something you almost had; you need to put this into the buildAgent.properties:
workDir=E:/MY_PROJECT_SVN
Update:
It should be noted that on TeamCity 7.0 the workDir seemingly can't be on a separate disk; it runs most of the way through the build and then fails. However, using a junction to point from the local (default) folder to the E: drive will work. The tempDir can be pointed to a remote disk though.
The file buildAgent.dist.properties is not used, it is just an example. So don't worry about the contents of that file.
What you have set in buildAgent.properties is what matters. What is happening for you is the agent is reverting to the default location for the working directory.
This means that for some reason it is not able to read or parse the buildAgent.properties file. Make 100% certain that the entire file has no errors in it.
https://confluence.jetbrains.com/display/TCD8/Build+Agent+Configuration
Making any change to this file and saving it should cause the build agent to reboot automatically and reload the new config once it has restarted.
http://blog.jetbrains.com/teamcity/2007/10/configuration-files-editing-without-teamcity-restart/
To build on paul-f-wood's answer:
Teamcity 9.1.6 also has the "feature" where the work directory cannot be on a different drive. I tried several permutations of the temp and work dir, and the only ones that stuck were with the work dir on the same drive as the root teamcity folder. However as paul said, using a junction works like a charm.
cmd: rm C:\BuildAgent\work
cmd: mklink /J C:\BuildAgent\work E:\MY_PROJECT_SVN
I'm creating a GUI in order to launch a batch file which then kicks off a Powershell script. The GUI compiles fine and everything works great, however when I go to deploy the file it doesn't actually include any of the empty directories my script relies on.
How can I add empty directories to be included in my published VB form during install?
I don't think you can. Why don't you just do
If Not Directory.Exists(dir) Then
Directory.Create(dir)
End If
for each directory? I would create a list of directories over which to enumerate and run this each time the application is run.
You can always use the post build step to either create the directories you need or do other logic that your program may need such as run a batch file or power-shell script
See the example below. It will create a directory Test in the output directory where the .exe is placed.
If I try to build an application with the application class outside the default package, so the application file path is /app/AppClass.mxml instead of /AppClass.mxml (as would normally be the case), Flash builder cannot launch the application for debugging because it is looking for the SWF in debug/app/AppClass.swf and the SWF is being output to debug/AppClass.swf instead. Changing the output folder to debug/app makes it put the swf in debug/app, but then it puts the application configuration file "AppClass-app.xml" in /debug/app/app and then that can't be found.
Is there a way to change only the SWF output folder, or the location of the xml configuration file in the run-configuration?
You may use symbolic link to created swf file - http://en.wikipedia.org/wiki/Symbolic_link
for example for Windows :
cd project/path/bin-debug/package/path/
MKLINK ClassName.swf project/path/bin-debug/ClassName.swf
and it's work
or you can use symbolic link for folder:
cd project/path/bin-debug/package/
MKLINK path project/path/bin-debug/ /D
I think I remember this worked for me. But it was long time ago. And, yes, it is a known problem, I also recall Adobe people mentioning it as a limitation of FB.
In my Ant script, you'll need to do the adjustments to reflect your actual file names and directory structure. Also note that it will make it more cumbersome to debug it from FB. You'll need to use the debugging target in Ant, and then connect the debugger to the running application (so that some info, especially on the startup) will be lost. The only way you would be able to debug it, though I've never tried it, is with the commandline tools (I'm not sure of adl syntax for breakpoints / printing / stack frames, so idk how to do it.
Also, for the released application you will probably want to change the signing mechanism.
My visual studio solution includes a web application and a unit test application. My web application uses log4net. I want to be able to use msbuild from the command-line to build my solution. However, whenever I build the solution from the command-line, I get build errors because it can't copy log4net.xml to the test project's bin directory.
The error message is:
"Unable to copy file '\bin\log4net.xml' to 'bin\Debug\log4net.xml'. Access to the path '\bin\log4net.xml' is denied."
It looks like Visual Studio is locking this file, but I can't figure out why it would need to. Is there a way to prevent VS from locking the XML documentation files in a project that it has loaded?
I've found the following solution:
In VS postbuild event or in NAnt/MSbuild script execute the cmd script
handle.exe -p devenv [Path to the folder with locked files] > handles.txt
FOR /F "skip=5 tokens=3,4 delims=: " %%i IN (handles.txt) DO handle -p %%i -c %%j -y
handle.exe is available here http://technet.microsoft.com/en-us/sysinternals/bb896655.aspx
first line of the script dumps to handles.txt all handles for files locked by VS
second line reads handle ids from the file and kills the handles
After the script is executed files may be removed/replaced/moved etc
If you're fine with omitting the xml & pdb files altogether from the output, you can pass /p:AllowedReferenceRelatedFileExtensions=none to msbuild on the command line.
(Thanks to related answer https://stackoverflow.com/a/8757941/251011 )
EDIT: If you also have problems with dll files having this error, I recently discovered an environment variable solution: https://stackoverflow.com/a/23069603/251011
I've had this problem with Visual Studio, too. We use NAnt instead of MSBuild, but the problem is the same. I was able to work around it by modifying the build file to ignore failures when copying xml documentation.
Note that this doesn't actually solve the original problem since the xml files are still locked, but this workaround was good enough for us since the actual content of our xml documentation doesn't change very often.
Krystan wrote:
You could drop this file into another directory and reference it from there or place code that uses it into a library and have the post build event on that copy it to its bin directory and then reference.
Our xml file locking problem is not in the projects bin directory, rather an external reference directory. We hit it when performing TortoiseSVN->Update where a new version is available. Assuming it's because VS is using the file for intellisense.
For those who hit this locking issue due to TortoiseSVN->Update, I'm currently experimenting with a pre-update hook which deletes the offending file(s) before updating (they will be restored if no update is needed), so far this seems to work (which is weird) but I haven't tested it thoroughly enough to say for sure. Will update this answer if it proves reliable.
Here's hoping MS fix it in VS 2010.
Basically don't check files into the bin folder, its a bad idea.
You could drop this file into another directory and reference it from there or place code that uses it into a library and have the post build event on that copy it to its bin directory and then reference.
Msbuild will then copy that to the webprojects bin directory for you :)
We have this exact issue with people checking in stuff to the bin directory, unless you absolutely have to bin directories should either not be checked in at all or just have .refresh files in there to avoid these sorts of locking issues.
Bit late on the reply, sorry :)