We have used the following TFS Deployment strategy used for Websites -:
1) Windows Machine File Copy
Source : Folder of TFS
Target : Application Server
Now, in a folder placed inside this website, files are first deleted and then added/ re-created.
But after deploying through TFS, files are made Read-Only. So files can't be deleted and error is thrown on the website.
How to handle this case in TFS deployment
I'm assuming your build a server workspace or you are directly pulling files from TFVC into a server workspace (see local vs. server workspaces). In a server workspace files that are not check-out are read in the workspace to prevent you from making changes locally without first telling TFS you are going to changes them (check-out). Since your build will usually not perform any source control operations in your workspace some or or all files remain read-only when you copy them or publish them as artifacts.
If you copy items from TFS to another location these read-only flags are also copied. However this is easily fixed by using attrib -r to clear the read-only flag either before publishing the artifacts from your build or before (or after) copying the files over to the target machine. See the attrib documentation for more options like recursion.
When you set a folder path as the Physical Path for a website in IIS 6.0, you will see that the folder are made to Read-only automatically.
You could remove the Read only setting for this folder in the folder property. If you want to remove the read only setting for your folder. In the Windows Machine File Copy step, you need to provide an account which is the administrator of the target machine.
Problem has been resolved by adding one attribute of Windows robocopy command.
/A-:R : Removes the Read only attributes from copied files.
"/A" : attribute
"-" : remove
"R" : Read only property
Related
I am trying to copy my build to a particular drop location. But instead of copying the some important files and directories it is copying all the solution file and directories there like .csproj files and .csfiles and also all the folders present there.
I only want to copy dlls(projects dlls and references dlls of the project) and some data Folders and files to drop location so that I can use them to execute my test cases. But it ends up copying the whole solution.
Below are the setting I am using to copy and publish build artifacts.
Can Anyone tell me how can it be done?
Note: when I tried to put $(build.sourcesdirectory)\bin in the copy root it gave me an error that "Cannot bind argument to parameter 'Path' because it is null".
I also tried putting only **.dll in my contents but then it copies nothing. The folder created in drop location comes empty.
You're telling it to publish **/*test*.dll, from the root of the build agent. That minmatch pattern is saying "find everything in every subfolder that matches test.dll", so the results you're getting aren't surprising.
What you probably want to do is specify the path to the binary output location of your test projects. Without seeing the structure of your code or what MSBuild variables you're providing/overriding, it's impossible to give more guidance. Look at the documentation on pre-defined variables and that should give you some ideas.
In general, you want to set your output folder (via MSBuild arguments) to $(Build.ArtifactStagingDirectory), so only build outputs go there. Then you can use that as your Copy Root.
Is there a way in teamcity to restore a deleted build configuration. I found Restore just deleted project which is about restoring a deleted project but can't find any information about restoring a deleted build configuration. I am using Teamcity 8.0.6
TeamCity 9, locate your data directory and you'll find a trash folder, like so:
D:\TeamCity\Data\config\_trash
Take a copy of the whole thing to some other folder, just in case.
Move the effected project folders from config\_trash to config\projects.
Remove the suffixed .projectNN from each project folder.
You may see critical errors in the main web portal while this is happening.
Restart TeamCity just for good measure.
The previous versions of build configuration setting are stored in /config/projects/buildTypes folder in different *.xml.N files. To restore setting replace *.xml file with *.xml.N file.
Also since TeamCity 9 it is possible to store all project setting in VCS.
Another option, available since 9.0 is to place project settings in version control (Git, Mercurial, or Subversion and Perforce since 9.1), and then restore removed files using VCS commands.
I made a huge mistaking in renaming my xml file from xcode and I'm not sure how to fix it. My app has a feature that reads all local xml files built with the project. So now it is reading 2 of the same xmls with different names.
I tried deleting the file, added it back in, and Dereferencing it but no luck. I also made sure to delete my app and re building the project. When I do a full system scan for the xml file nothing pops up. The xml file is currently in the Trash.
Another issue might have been with the svn remote server but I tried svn rm --delete filename and it said the file does not exist. ( I tried the project directory as well as a few other sub directories).
Is there a way to Dereference/delete the file from the project?
My Visual Studio 2013 Custom Build Tool step is failing because the directory in which the step is being executed is not the directory where the project file is (which was by default the case up until recently). I can patch it by adding a cd command to the start of the step to change to the project directory but I was wondering if anyone could tell me
how this directory path is set
how to change it.
The build always assumes the project directory as 'base' directory.
This gives msbuild a set location (Builds to bin\debug is a subfolder off 'Base', reference hint paths and a lot more besides).
I would just change the execute of your tool to be reference based (i.e ....\tool.exe or similar) or make use of the path environment variables ($(OutDir),$(TargetPath),$(ProjectPath),$(TargetDir) etc).
Another option that I make use of is to have a batch file called 'post.bat' that has the necessary steps to execute a custom tool. This is then placed in the project folder and added to the project as an artefact.
Without knowing exactly where your custom tool resides relative to the project (or solution) or what the 'working directory' requirements of the custom tool are I cannot suggest more.
Inside the project folder there is a "project's name" folder, Release and Debug folder. I'm right now working in debug mode and my files keep getting updated everytime i run it, and i copy it into the other 2 folders everytime to avoid confusion. Is this the right way to do it or is it enough if the files are in the main folder ?
If you have files in the project that need to be copied to the current output folder on build then select the appropriate options in the file's properties: select the file in solution explorer and then set the properties of that file:
Build Action: None
Copy to output directory: Copy Always, or Copy If Newer.
Thus VS will put the files in the right place on build. You do not need to maintain multiple copies.
If your program needs access to text files, images, etc. which are separated from the program's code, you can put these both into the debug or into the release folder.
Beware that if you modify these files into the debug folder, you must update the files into the release, and vice-versa. This is valid if you use to switch between the debug mode and the release mode. If you use only the debug mode as I do while I'm developing, you could put all the files in the debug folder only, and copy these files into the release folder only when you will end the development.