Building my solution succeeds, but the build fails upon copying from the build to the drop location. I get an error like this
TF270002: An error occurred copying files from 'E:\Workspace' to '\\server\drop location_20101026.25'.
Details: Access to the path '\\server\drop location_20101026.25\_PublishedWebsites\website\bin\somecompiled.dll' is denied.
This is a part of a continuous integration build (as well as several other types of build that I've tried). This is a copied build definition from a definition that has worked for several months now, running on TFS 2010.
Yep, I was right, I did this myself by putting the copy to drop location task in the parallel foreach loop, resulting in the task being done 3 times, and causing my problems.
Related
We have a C++ application using MFC. We also use the manifest that is auto-generated and we actually do use it.
The environment is windows server 2012 it has TFS 2018 installed on it and a build agent configured. Visual studio 2017 pro 15.6.2 is also installed with all the needed packages for our project.
The weird thing is when I compile the project within visual studio everything is build just fine BUT when I build with the build agent on the same machine there is an error:
Generating code
All 26621 functions were compiled because no usable IPDB/IOBJ from previous compilation was found.Finished generating code
C:\_TFS(0,0): Error c1010070: Failed to load and parse the manifest. The system cannot find the file specified.
C:\_TFS : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
LINK(0,0): Error LNK1327: failure during running mt.exe
LINK : fatal error LNK1327: failure during running mt.exe [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
Done Building Project "C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100.sln" (default targets) -- FAILED.
Build FAILED.
"C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100.sln" (default target) (1) ->
"C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj" (default target) (4) ->(Link target) -> C:\_TFS : general error c1010070: Failed to load and parse the manifest. The system cannot find the file specified. [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
LINK : fatal error LNK1327: failure during running mt.exe [C:\_TFS Build Agents\DEUSRV52\_work\1\s\test\App\HC100\HC100.vcxproj]
0 Warning(s)
2 Error(s)
Time Elapsed 00:02:11.68
Process 'msbuild.exe' exited with code '1'.
Now it says that a certain file cannot be found except that the file is actually there. My guess is that something else might be wrong here.
So I went to the folder where the sources are being placed via the get sources task which is in the agent's folder structure and I then opened the solution with visual studio and build it there and again within visual studio the build is successful.
I've been looking on the internet and I found a couple of solutions such as:
disable manifest creation in the linker options menu... (this is not a solution for us since we need it)
mt.exe can't cope with spaces in the file path (strange since when opening the same files in visual studio it does build or is there something different when opening it from VS or building it with an agent?)
Digital Guardian might restrict execution (we don't have that nor can I see it in procmon)
A virus scanner might block execution (nothing is installed on the environment)
when using the Visual studio build step instead of msbuild build step in the TFS build system the build fails with exactly the same error.
I'm pretty sure that it has nothing to do with points 3 and 4 (virus scanners/ security restrictions) since I can build it successfully within the visual studio itself.
I just started to use TFS build for the first time so there is a big chance that I'm missing something here. Hopefully, someone can help me out.
I have asked this question on MSDN forums as well (https://social.msdn.microsoft.com/Forums/en-US/587b1c42-8ac6-4deb-95aa-4d74c91fd55f/msbuild-issue-on-windows-server-2012-link1327-mtexe-error-c1010070?forum=Offtopic) where I got the suggestion to ask the question here as well.
The issue is found and we have a workaround implemented.
When an Agent is defined in a path that has spaces in it mt.exe will not be able to find a file within that path. But this gets stranger because when you have a path that contains spaces and you run msbuild.exe via the command line mt.exe will find the path and the build is successful. after some testing we found out that if you combine the execution on an agent (which is located in a path that has spaces) the execution of mt.exe by the agent will have this error that mt.exe is not able to find the file. Now to completely test this and to make 100% sure that this has something to do with the agents path I created a build definition with specific execution paths. So I disabled the get sources step, removed all the sources then placed all the sources in a space free path and then ran the msbuild commands on an agent that contains spaces in its path and then it failed again.
So what we settled for is to locate our agents in a path that does not contain any spaces and now it builds just fine.
i'm using TFS2015 and vnext builds to build projects and sln files with build controller
in projects or slns we use robocopy command to copy dlls from builded solution to other folders but sometimes this job done and vnext build passed successfully and sometimes robocopy command can't copy dlls and failed with error
is there anyone solved this problem, can help me ?
1-my build agents run with Network/Service User
2-robocopy command error exited with code 8.
Error 8 from Robocopy means that some files or directories could not be copied at that moment. Since you are saying that the command sometimes succeeds, more likely is either a specific time related issue, or probably the files are being used by some other process at the time when the command is executed. In both cases you could try to execute the same robocopy command manually several minutes later, and see if it will fail again. You could add a /v option in your robocopy command (and possibly /LOG), and verify if there is more descriptive error in the log file afterwards. Also, when it fails, is the environment same as the one, on which it succeeds?
I'm running latest version of TFS 2015 release manager. I have a simple release that includes a "CopyFiles" task. I need to have the "Clean Target Folder" option of the task enabled.
I have three target environments configured. Both are newly created identical Windows servers. The CopyFiles task works fine against the first two servers but for the next environment in the pipeline, when copying to the second server I get the following error:
2016-11-11T21:41:07.4324714Z found 2 files
2016-11-11T21:41:07.4324714Z ##[debug]file:D:/Build/_work/df9f2c4cf/(master) Orchard BTDF/drop/20161111.5.zip will be copied.
2016-11-11T21:41:07.4324714Z ##[debug]file:D:/Build/_work/df9f2c4cf/(master) Orchard BTDF/drop/Unzip.ps1 will be copied.
2016-11-11T21:41:07.4324714Z Cleaning target folder: \\Steatbt02\BizTalkDeployments2\Orchard
2016-11-11T21:41:07.4324714Z ##[debug]rm -rf \\Steatbt02\BizTalkDeployments2\Orchard
2016-11-11T21:41:07.4480915Z rm: could not remove directory (code EPERM): \\Steatbt02\BizTalkDeployments2\Orchard
2016-11-11T21:41:07.4480915Z ##[debug]task result: Failed
There's no sign of errors in the event log.
I created the share "\Steatbt02\BizTalkDeployments2" and granted "full-access" permissions to the account running the build agent. I even tried logging onto the build server and run as for the command prompt using the credentials of the build agent. From this command window I was able to remove the target folder
"\Steatbt02\BizTalkDeployments2\Orchard" - so I can't think why the build agent would have trouble doing the same!
Any ideas what could be wrong, or what extra steps I could take to track down the root cause of the problem?
The problem was the agent queue selected for the problem environment.
I seem to be getting a lot of pain with the processing of app.config and token files (we have this working with the older ".11" templates).
It looks like currently (using the ReleaseTfvcTemplate.12.xaml) this is running the tokenisation after the build.
While I can make the app.config / myapp.exe.config stuff work by deliberately copying the .token file into my output folder (so the recursive search finds it) this feels pretty horrid.
As a fix I'm tempted to move lines 182-230 to just before the RunMSBuild task on line 175 (creating a new sequence at that point)
Is this the correct approach or have I missed some documentation somewhere (or a later version of the template?)
Thanks guys... Anyway for future reference I did make the change.
However I had misunderstood the exact nature of the order things happen out of the box which is as follows:
Get the project out of source control
build with msbuild
Copy the .config.token file over the .config file. This is in the TFS template
As part of the deploy to a server then the token entries in the .config files are replaced. This is in the release manager template.
Tests are run in the msbuild binary output folders.
The problem is this doesn't really work if you're using an project type that uses app.config file as the msbuild process renames these output.exe.config during the msbuild stage so you need to create both an output.exe.config (marked as copy to output) and an output.exe.config.token so when the post deploy is the final output gets configured correctly. This also a problem if you want to tokenise some mstest dlls as these typically use an app.config as well. Basically this is a bit of a mess unless you are using web.config.
We worked our way around this by using the modification I suggested above (you need to create a sequence at line 175 and move lines 178-230 up into the sequence, this is GetBuildDirectory variable bits and the if statement) followed by adding an additional deployment stage which copies back onto the build server with the new tokenised files so the mstest can run against them.
So our new process looks like this:
Get the project out of source control
Copy the .config.token file over the .config file i.e app.config.token copied over app.config
build with msbuild (this means we end up with tokenised myapp.exe.config and mytests.dll.config)
As part of the deploy to a server then the token entries in the .config files are replaced. This is a release management step in the release template.
Deploy the tests back into a folder on build server (think this has to be a fixed folder until update 4 of release manager is deployed) the token entries in the .config files are replaced (so our integration tests can use the newly deployed servers). This is a release management step in the release template.
Tests are run in the fixed folder on the build server (rather than the msbuild output directory) so the test wildcard needs to be changed in the tfs build template.
Quick final note we don't use that build directory variable and it's left at blank I'm not convinced this would work if it was set to a value...
The replacement of variables in config files with Release Management happens at deployment time and not at compile time.
When RM deployes your app it inserts the correct variables.
It sounds like you're hitting one of two issues:
You need to include the .token file in your project and make sure it's set to Copy Always, so that it gets copied to the build output folder.
If you're building a web application, I've seen a bug in the release build process template that doesn't touch the contents of the _PublishedWebsites folder. I don't know if it's been fixed in Update 4 or not, but it was definitely still a problem in earlier versions.
When an ANT build step fails in my build I'd like to archive the logs in order to determine the problem. The relevant logs, however, are not located in the workspace, so I have to use a full path to them.
The standard artifact archiving feature does not work well with full paths, so first I have to copy the logs into the workspace within some build step so that I can later archive them. I do not want to incorporate the copying code into the original ANT script (it does not really belong there). On the other hand, since the build step fails the build I can't execute the code that copies the artifacts into the workspace as a separate build step as it is never reached.
I am considering using ANT -keep-going option, but how will I then fail the build?
Any other ideas (artifact plugins that handle full paths gracefully, for example)?
Update: I've worked around the problem by creating a symbolic link in the workspace to the directory that contains the files to be archived. Kludgy, but effective.
I would recommend using Flexible Publish plugin in conjunction with the Conditional Build Step plugin.
The Flexible Publish plugin allows you to schedule build steps AFTER the build steps have normally run. This allows you to catch both successful and failed builds and execute something - say a script that copies the files from OUTSIDE the workspace to INSIDE the workspace. The Conditional BuildSet plugin allows conditionalizing the steps so that they only run when the build fails. Using these two plugins, you can copy the files into the workspace upon failure, then archive them with the usual Jenkins mechanisms.