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
Related
I installed the Visual Studio 2019 Build Tools with the help of offline installation in a windows machine which has a Jenkins server running on it. On this machine there was already VS2013 and VS2017 installed previously. I did not uninstalled those, I just left it as was.
Whenever I now start a job in Jenkins, it is complaining that it can't find msbuild and it can't find nuget .
I added to the PATH environment variable to
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuilsTools\MSBuild\Current\Bin;
and a variable msbuild to
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuilsTools\MSBuild\Current\Bin\MSBuild.exe
but it didn't help. If I type echo %PATH% and echo %msbuild% I see the right links.
I closed all the shells, I restarted the computer, I restarted Jenkins.
Is there anyway to set all the variables the Build Tools need automatically? Anyone has another idea what I could try?
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 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.
I try to configure Hudson (3.1.0) to build Delphi XE3 project (MSBuild).
Batch for build:
call "C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\rsvars.bat"
msbuild "X:\Tests\DelphiTest\Project1Test.dproj" /t:Build /v:minimal /p:config="Debug"
Run this batch in command line (cmd.exe) - build correct.
When I put this batch into Hudson build step faild with errors from delphi compiler:
[..]
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\bin\CodeGear.Common.Targets : warning : Expected configuration file missing - C:\Windows\system32\config\systemprofile\AppData\Roaming\Embarcadero\BDS\10.0\EnvOptions.proj
_PasCoreCompile:
Embarcadero Delphi for Win32 compiler version 24.0
Copyright (c) 1983,2012 Embarcadero Technologies, Inc.
C:\Program Files (x86)\Embarcadero\RAD Studio\10.0\Bin\CodeGear.Delphi.Targets(172,5): error E1026: File not found: 'Controls.res'
[..]
In fact I don't have missing file in this location. But I've found it in
C:\Users\<username>\AppData\Roaming\Embarcadero\BDS\10.0
So I try do dummy think like copy existing dir to missing location but it doesn't work.
I'm using: Delphi XE3 Enterprise, Win 7 Ultimate (x64)
Thanks for help.
this usually happens the first time you run MSBUILD or DCC32 on a machine which has never had the IDE gui open (bds.exe) and which has passed the mandatory startup environment configuration tasks that happen inside BDS.exe.
If you log in on Hudson or Jenkins as a Windows service using an account that has never been used for Windows logins, has never run BDS.exe, you will get this issue. The MSBUILD utility from Microsoft must invoke DCC32, which is licensed commercial software, and the Delphi command line compilation licensing and environment configuration requires that you have run the IDE as the account, and that your jenkins build account and computer is licensed properly.
Solution:
Either change Jenkins or Hudson to log in as an account that has a license to run Delphi, and has run Delphi at least once.
If you can't change the server login, then log in interactively (via remote desktop) using the account that Jenkins/Hudson is using, and configure Delphi (Rad Studio) so it runs fine from that account.
Update 2015: I am now running into a whole new class of problems related to Group Managed Service Accounts. They were working with Delphi XE8, but I am not able to get a GMSA account to work with Delphi 10 Seattle. I'll update this answer if I ever do figure out a way, but for now, I recommend conventional service accounts, not GMSAs, for Delphi continuous integration with Jenkins or Continua, or others. Also check Delphi.wikia.com for more tips: http://delphi.wikia.com/wiki/Setting_up_a_Delphi_Build_Machine
We recently ran in a similar kind of problem. We are trying to compile our projects on an jenkins. We simplified the "build" script to the following 2 lines
call "[....]Embarcadero\Studio\18.0\bin\rsvars.bat"
MSBuild.exe /p:config=Release /target:Rebuild Project2.dproj
This is building the project successful.
But when we switch to /p:config=debug the build fails with the known errors about missing *.res files. We looked up in the delphi lib/win32/ directory and realized that there are *.res files in the release folder but not in the debug folder. We now further modified the msbuild command to this:
MSBuild.exe /p:config=Release /target:Rebuild /p:ResourcePath="%BDS%\lib\win32\release" Project2.dproj
And this is compiling just fine. So apparently the compiling in debug mode lacks the path to the delphi sources (which are included in several subfolders in %BDS%\source\
So as a workaround we can compile debug builds using jenkins and simply giving delphi the *.res files from its release folder. But that can only be an intermediate solution.
Maybe this information helps someone to find a final solution which is not "Adding all subfolders of %BDS%\source into the search path" ;-)
Consider a .csproj containing the following directive:
< Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
There's a standalone TFS Build service installed on a machine, with a default Controller and one Agent. The TFS components were installed; Visual Studio was not installed.
When compiling an ASP.NET MVC 2 Web Application (targeting .NET 4), the TFS Build service encounters an error:
C:\somepath\foo.csproj (219): The imported project "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
TF270015: 'MSBuild.exe' returned an unexpected exit code. Expected '0'; actual '1'.
It's true: there's no sub-directory "WebApplications" in the "C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0" directory.
It seems that this subset wasn't included in the install of the TFS Build service. TFS doesn't give any options on what pieces are installed for Build service.
What's the most appropriate way to install these artifacts, and any dependencies, on this TFS Build machine? Could this have been avoided?
Have you tried creating the path C:\Program Files\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\ manually and copying the file Microsoft.WebApplication.targets there? If Microsoft.WebApplication.targets doesn't contain references to some specific build tasks that should do the trick.
At least that worked for Visual Studio 2005.
Check for unwanted references like 'stdole.dll' in your references and remove it.
connect to tfs again (to refresh)
try to build again.
Best solution is to always install VS2010 on your build machine.