I have configured TeamCity to work with our TFS repo. I have configured the VCS Root and used the "Test Connection" to ensure that the settings are all correct. When I run a build it gets to the "Updating sources" and just hangs there. Here's the build log.
[13:33:45]Collecting changes in 1 VCS root
[13:33:47]Clearing temporary directory: D:\TeamCity\buildAgent\temp\buildTmp
[13:33:47]Publishing internal artifacts
[13:33:48]Using vcs information from server. Reason: no revision information for build configuration "Build Development trunk" and checkout directory D:\TeamCity\buildAgent\work\db23c120e1319dcb on agent
[13:33:48]Clean build enabled: removing old files from D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Checkout directory: D:\TeamCity\buildAgent\work\db23c120e1319dcb
[13:33:48]Updating sources: server side checkout (1m:21s)
[13:33:48][Updating sources] Will perform clean checkout
[13:33:48][Updating sources] Clean checkout reasons
[13:33:50][Updating sources] Building and caching clean patch for VCS root: Development trunk
The checkout folder is empty. Any ideas?
EDIT
I've written a Windows batch file that gets the code out from TFS rather than using TeamCity to do this. My batch file runs perfectly when run from the Windows command prompt but fails when run from TeamCity. I am using the fully qualified path to TF.EXE because TeamCity doesn't seem able to find TF.EXE (even though the path has been added to the PATH environment variable).
My batch file correctly configures the TFS workspace before trying to GET the source code. But it still fails.
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /collection:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workspaces /s:http://code-srvr1:8080/tfs/DefaultCollection
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" workfold //fails!!
"C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\tf.exe" get $/MSM\Development\Trunk /force /recursive //fails!!
The error I am getting is "Unable to determine the workspace. You may be able to correct this by running 'tf workspaces /collection:TeamProjectCollectionUrl'"
But as can be seen I am already specifying the workspace in the batch file.
Any ideas why these commands work from the Windows command line but fail from TeamCity? How do I get them to run from TeamCity?
The solution in my case was to upgrade my Team Foundation Client from 2012 to 2013. There are known timeout issues with the 2012 version and upgrading to 2013 has resolved these.
I had the same issue (TeamCity builds that fetched code from TFS would get stuck indefinitely at the Updating sources stage, blocking the agent).
The solution for me was to make sure that the TeamCity Build Agent ran under the same service account as the TeamCity Server. The server would be able to access the TFS project and instruct the agent to do a build, but the agent itself got stuck when it was not authorized.
When that account mismatch was fixed, it all started working as it should.
As a side note, when the parameter “teamcity.tfs.mode=java” is set, the TeamCity agent does not get stuck, but instead fails with an instructive error message (detailing the current service account name), if it runs under an unauthorized account.
Related
Fairly new to Azure DevOps and PipeLines, but we are stumped by the fact executing an MSBuild command locally or through publish in VS2019 gives us a complete ready to publish folder, while the same command in Azure DevOps pipeline seems to be doing nothing but build.
Local command:
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\msbuild" Webshop\Mvc.csproj /p:PublishUrl="c:\Publish\Mvc" /p:DeployOnBuild=true /p:Configuration=Release /p:WebPublishMethod=FileSystem /p:DeployTarget=WebPublish /p:AutoParameterizationWebConfigConnectionStrings=false /p:SolutionDir="." /p:PrecompileBeforePublish=true
MSBuild task:
steps:
- task: MSBuild#1
displayName: 'Build solution'
inputs:
solution: '$/MVC_Projects/<more here>/Webshop/Mvc.csproj'
msbuildVersion: 16.0
platform: '$(BuildPlatform)'
configuration: '$(BuildConfiguration)'
msbuildArguments: '/p:DeployOnBuild=true /p:DeployTarget=WebPublish /p:PublishUrl="$(build.artifactstagingdirectory)\publish" /p:WebPublishMethod=FileSystem /p:AutoParameterizationWebConfigConnectionStrings=false /p:PrecompileBeforePublish=true'
We tried playing with the parameters, but that does not seem to have much effect (or we don't know which parameters to tweek). The most we got was adding an /p:DeployTarget=Package and /p:OutDir="$(build.artifactstagingdirectory)\bin" would copy the bin folder. This was still without the .compiled files we were expecting though.
The project is an ASP.NET MVC Framework 4.8 application. The code does build properly and without errors. The logs do not hint with any warning or tasks not being able to be completed, so no clues there. We require the output folder for the full website and not just the DLL's to make our migration to DevOps easier. Having the folder allows other deployment processes to remain the same.
This might not be best practice, but it is practical for us at this moment in time.
Question 1. Why is MSBuild doing something else locally than in the DevOps Pipeline? Is it perhaps picking up configuration files we are unaware of ?
Question 2. What settings (or perhaps other task) would we need to set up to get the same local publish folder appear in the $(build.artifactstagingdirectory) folder in DevOps ?
Any insight, direction or solution is appreciated.
SOLUTION
After many checks and trials in the build parameters and pipeline setup, it was a DevOps server installation issue. The DevOps server had a full version of 2022 installed and only a partial version of 2019. Although the builds did not give any error or warning, the artifacts were not created without the 'ASP.NET and web components' for Visual Studio 2019 being installed. After that component was installed, the builds ran just fine and as expected.
Lesson learned is to double check local development installation with server installation with relation to installed (individual) components when results vary, even if there are no errors.
I am getting an error while creating a Continues integration with TFS -database project. please find the attached screenshot and help me to move forward with my plan.
and also getting doubts on the below things
How to set the working directory in build service,
What to give the Source control folder and build agent folder.
MS Build arguments.
enter image description here
In TFS 2013, build system uses the MSBuild to build the solution/project on the build agent machine. The error in the screenshot means the SQL Server Data Tools need to be installed on the build agent machine.
In TFS Test Task I know that I can manually set the location of vstest.console.exe via:
this is less than an ideal solution though since, as I update my build server, this location may become invalid. The problem that I have run into is that if I select 'Version' my build server ends up using the vstest.console at this location:
C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL\Common7\IDE\CommonExtensions\Microsoft\TestWindow
I am guessing that this SQL Folder is the SQL Server Data Tools folder that is installed on the build server. This folder location isn't generally a problem, vstest runs my unit tests and reports back on them, however, it doesn't produce a code coverage report. I initially thought that this was due to an improper configuration of the builds, however after verifying that the build was setup correctly and that the server had all of the necessary dependencies I started looking for other causes. I opened up the .trx file from one of the builds and noticed that the DataCollector logged a message that it couldn't find CodeCoverage.exe. After some more troubleshooting, I pointed my build to the location of the vstest.console shown in the image above and everything (tests, code coverage) ran fine. This leads me to believe that vstest expects the path:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Team Tools\Dynamic Code Coverage Tools
to exist relative to where it is run from and that directory (Dynamic Code Coverage Tools) does not exist inside the SQL folder.
Is there a way to change the path that TFS uses when the 'Version' checkbox is checked?
VsTest task uses vswhere.exe in order to determine the latest version of VS installed in the machine. Can you try to run vswhwere.exe and check which version of VS is installed at C:\Program Files (x86)\Microsoft Visual Studio\2017\ SQL folder and is it higher than other versions, also check whether its an enterprise installation or not. As code coverage is provided as part enterprise installation only.
You will be able to find vswhere.exe in agent working folder as per VSTest task version eg.
C:\Temp\Agents\127Agent_work_tasks\VSTest_ef087383-ee5e-42c7-9a53-ab56c98420f9\2.3.19\vswhere.exe
I am trying to build a Visual Studio VC++ solution/project on jenkins build server through batch script that uses msbuild.
The script runs on my system( Win &, Visual Studio 2012 enterprise), without problems.
In the jenkins server , the batch script ran into following problems:
1)It was searching for
C:/Microsoft.Cpp.Default.props
and hence build would fail.
I created VCTargetsPath key with value (MSBuildExtensionsPath32)\Microsoft.Cpp\v4.0\ under registry setting
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0
on Jenkins machine and then it would search correctly under
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110
and the error was gone.
2) CL.exe could not be located on Jenkins.
Added C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\bin
to system env Variable "PATH" and the error was gone.
3) Now, finally I am getting following error
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.CppCommon.targets(347,5): error MSB6006: "CL.exe" exited with code -1073741701
Is there a way to get more information about the error? or any other solution?
I also got information from colleague that adding C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V110 to Jenkins causes known bug in Jenkins, and I don't know that the subsequent build error is due to that or something else?
Note: What is even more confusing is that running the same batchscript from command prompt on Jenkins executes without any such issues but doing it from within Jenkins build server IDE/framework causes issues.
Thanks
sedy
installing full Visual Studio on the server solved the problem. The issue was that server did not have 64 bit version of VS installed and so won't build that.
sedy
On my local dev machine this works perfectly:
msbuild project.name.csproj /p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
I'm trying to configure a Build step in TeamCity with MSBuild, in the "Command line parameters" I'm putting this:
/p:DeployOnBuild=true /p:DeployTarget=PipelinePreDeployCopyAllFilesToOneFolder /p:_PackageTempDir="c:\proyectos\folder1\deploy" /p:AutoParameterizationWebConfigConnectionStrings=false
It runs, no errors are displayed, but files are not copied to "c:\proyectos\folder1\deploy"
Edit: I'm having the same issues with MSBuild on the command prompt, so it's not teamcity. My local dev machine is on windows 7 and the server is windows 2003
Run with /v:d or v:diag to get logging.
(Get it working local first but... In TeamCity, view the agent in the console and look at the agent detail logs for similar such logs (or just pass the same /v: flag to MSBuild via TeamCity))
You'll want to ensure that the user running the "TeamCity Build Agent Service" has write access to the relevant directories.
(FWIW, I believe the LocalSystem account has different group memberships in Server 2003 and Windows 7. We run all of our TeamCity build agents under their own "teamcity" accounts to more explicitly control permissions and allow access to network shares.)
Installing Visual Studio 2010 DOES fix this problem. But, you can also fix it by copying the appropriate build targets to your machine. Typically, on your dev machine they'll be at (Or take away the (x86) for 32 bit machines):
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\Web
In there you'll find a bunch of Microsoft.Web.Publishing.* targets.
Just copy those over to the equivalent location on your build machine and all will be well.
Installing Web deploy tool through web platform in the server works for me. Actually visual studio installation installs web deploy, It might be the reason why it works for #himinaya.