I am building with TFS 2017. I am currently receiving this in my log:
[error]Core\Install\CSharp.nuget\NuGet.targets(87,9): Error : Unable to find version '9.0.1' of package 'Newtonsoft.Json'.
as well as some other packages. Immediately following, I have this:
[error]Core\Install\CSharp.nuget\NuGet.targets(87,9): Error MSB3073: The command ""E:\agent01\31\s\Core\Install\CSharp.nuget\nuget.exe" install "E:\agent01\31\s\Core\Source\Core.PackageReference\packages.config" -source "" -RequireConsent -solutionDir "E:\agent01\31\s\Core\Install\CSharp\ "" exited with code 1.
I am only switching builds from 2013 to 2017 and know that they should work without going inside of config files and changing anything. The only changes I should have to worry about are with the build machine or in the tasks I've created for this build. I was wondering what potential solutions someone may have.
I have a nuget restore task and all of the correct solutions are being built.
Looking in to my nuget restore task, I see near the bottom:
Adding package 'Newtonsoft.Json.9.0.1' to folder 'E:\agent02\12\s\Core\Source\packages'
The issue I found was with the build task. I had sent it to an output directory and that had caused the error.
Related
I am very much new in TFS framework, and now i am creating build from last 3 days, all steps passes but fail # Build Solution with error:
[error]Process 'msbuild.exe' exited with code '1'.fails.png
My versions are:
TFS version: Version 15.105.25910.0
VS version: Microsoft Visual Studio Enterprice 2017 (15.9.4)
Can anyone from community tell me whats going wrong with my build.
Build Error:
2018-12-29T11:48:37.1011337Z ##[section]Starting: Build solution
*.sln 2018-12-29T11:48:43.4372323Z ##[command]"C:\Program Files (x86)\MSBuild\14.0\bin\msbuild.exe"
"\localhost\ARM-Drop1\1\s\LetsGo1\LetsGo1.sln" /nologo /nr:false
/dl:CentralLogger,"\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll";"RootDetailId=f568d794-328b-48cf-a753-e603bc019eed|SolutionDir=\localhost\ARM-Drop1\1\s\LetsGo1"ForwardingLogger,"\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll"
/p:VisualStudioVersion="14.0"
/p:_MSDeployUserAgent="TFS_29388952-19c1-40f9-b321-9389f9ab526b_build_17_287"
2018-12-29T11:48:43.5382020Z MSBUILD : error MSB1021: Cannot create an
instance of the logger. Could not load file or assembly
'file://\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll'
or one of its dependencies. The system cannot find the file specified.
2018-12-29T11:48:43.5392017Z Switch:
CentralLogger,\localhost\ARM-Drop1_tasks\VSBuild_71a9a2d3-a98a-4caa-96ab-affca411ecda\1.0.45\ps_modules\MSBuildHelpers\Microsoft.TeamFoundation.DistributedTask.MSBuild.Logger.dll;RootDetailId=f568d794-328b-48cf-a753-e603bc019eed|SolutionDir=\localhost\ARM-Drop1\1\s\LetsGo1
2018-12-29T11:48:43.7011531Z **##[error]Process 'msbuild.exe' exited
with code '1'. 2018-12-29T11:48:43.7871273Z ##[section]Finishing:
Build solution **.sln
I have resolved this bug, as I had done lot of changes into the solution file and the build definition in order to resolve the issues but no luck, so the quickest way I have in my mind is to delete the build definition plus uninstall the agent and again reconfigure it with appropriate agent capability and create new build definition and its all work as expected and the build definition got succeeded.
I'm working on a non-XAML TFS build; my solution includes a number of WiX installer projects. I've installed the WiX.Toolset.2015 NuGet package in each installer project. My solution builds successfully in Visual Studio and .msi installer files are produced for each WiX project as expected.
But, when I kick off a TFS build, the Get Sources step returns an error.
From the step logs, it appears that the WiX NuGet package content has been successfully copied to my build server (see log extract below, particularly ThmViewer.exe):
2018-07-27T09:25:08.2583873Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503:
2018-07-27T09:25:08.2583873Z Getting content
2018-07-27T09:25:08.2583873Z Getting readme.txt
2018-07-27T09:25:08.2583873Z Getting tools
2018-07-27T09:25:08.2583873Z Getting WiX.Toolset.2015.3.10.0.1503.nupkg
2018-07-27T09:25:08.2583873Z
2018-07-27T09:25:08.2583873Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\content:
2018-07-27T09:25:08.2583873Z Getting WiX.Toolset.DummyFile.txt
2018-07-27T09:25:08.3365150Z
2018-07-27T09:25:08.3365150Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools:
2018-07-27T09:25:08.3365150Z Getting Install.ps1
2018-07-27T09:25:08.3365150Z Getting Remove.psm1
2018-07-27T09:25:08.3990132Z Getting Uninstall.ps1
2018-07-27T09:25:08.4615127Z Getting wix
2018-07-27T09:25:08.4615127Z
2018-07-27T09:25:08.4615127Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix:
2018-07-27T09:25:08.4615127Z Getting candle.exe
2018-07-27T09:25:08.5084025Z Getting candle.exe.config
2018-07-27T09:25:08.5396418Z Getting darice.cub
2018-07-27T09:25:08.6490185Z Getting dark.exe
...
2018-07-27T09:25:10.3365325Z Getting smoke.exe.config
2018-07-27T09:25:10.4146591Z Getting ThmViewer.exe ***
2018-07-27T09:25:10.4615352Z Getting torch.exe
...
2018-07-27T09:25:12.5865476Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix\doc:
2018-07-27T09:25:12.5865476Z Getting bal.xsd
2018-07-27T09:25:12.7584269Z Getting complus.xsd
2018-07-27T09:25:12.8209262Z Getting Dependency.xsd
2018-07-27T09:25:12.8834264Z Getting difxapp.xsd
...
Then, further down the logs for the same step (Get Sources), we see:
2018-07-27T09:25:35.1492409Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix\ThmViewer.exe: Could not find file 'D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix\ThmViewer.exe'.
2018-07-27T09:25:42.2586735Z
2018-07-27T09:25:42.2586735Z ---- Summary: 0 conflicts, 0 warnings, 1 errors ----
2018-07-27T09:25:42.2586735Z D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix\ThmViewer.exe: Could not find file 'D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix\ThmViewer.exe'. ***
2018-07-27T09:25:42.5868038Z ##[error]Exit code 1 returned from process: file name 'tf', arguments 'vc get /version:887970 /recursive /overwrite D:\[build_folder]\[build_subfolder] /loginType:OAuth /login:.,******** /noprompt'.
2018-07-27T09:25:42.6024247Z ##[section]Finishing: Get Sources
I have other NuGet packages installed in other projects in this solution; all other sources are recovered without issue.
I've double-checked the packages source folder on my local machine and the ThmViewer.exe is in the \packages\WiX.Toolset.2015.3.10.0.1503\tools\wix folder as expected; all sources are checked into TFS.
I'm struggling to understand why the ThmViewer.exe file can't be found on the build server despite the logs indicating its successful copy. I'd be very grateful for any insights that may help to resolve the issue.
Thanks.
Just as Daniel said, we don't recommend to get the nuget packages in source control, you should use NugGet package restore.
Whatever just try below things to narrow down the issue:
Check if you can find the file
D:\[build_folder]\[build_subfolder]\Source\packages\WiX.Toolset.2015.3.10.0.1503\tools\wix\ThmViewer.exe
under the work folder on build server. If it's not there, then it
will not work.
Shrink the path length.
Cloak the packages folder, add a Nuget Restore task to restore the
packages
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 trying to do a teambuild for a VS2015 solution with TFS2013.
On the buildserver VS2015 is installed and I changed the buildtemplate so msbuild has an argument \tv:14.0, but when a start a build I get the following error:
C:\Program Files
(x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets (96):
Invalid static method invocation syntax:
"[Microsoft.Build.Utilities.ToolLocationHelper]::GetPlatformSDKDisplayName($(TargetPlatformIdentifier),
$(TargetPlatformVersion))". Method
'Microsoft.Build.Utilities.ToolLocationHelper.GetPlatformSDKDisplayName'
not found. Static method invocation should be of the form:
$([FullTypeName]::Method()), e.g. $([System.IO.Path]::Combine(a,
b)).
The buildserver has been restarted but I still get the error.
I also checked this thread: Build failed in TFS but no real answer was given there. Is there anyone that knows how to solve this.
I was experiencing the exact same error. I determined that TFS2013 was the RTM version so we installed TFS2013 Update 5. Now if I run using the *.12.xaml process template with the /tv:14.0 /p:VisualStudioVersion=14.0 parameters the build succeeds. I have also made a copy of the *.12.xaml build process and named it *.14.xaml and changed the Run MSBuild steps ToolVersion property to "14.0" and this build works as well, without the parameters.
You need to customize the build process template by finding all the Run MSBuild for Project MSBuild activity, then set the ToolVersion to "14.0" and set ToolPath to target to MSBuild14 (by default: "C:\Program Files (x86)\MSBuild\14.0\Bin"). After that, check in the build process template and re-queue the build.
Check the solutions here:TFS 2013 building .NET 4.6 / C# 6.0
I am moving our source code from Vault to TFS, not bothering with the migration or anything, just pulling a get latest in vault and adding it to TFS.
The solution has got several projects, and each one has at least one NuGet package. I am trying to get Package Restore working again. It worked in Vault (but not the way it was supposed to). I was under a bit of a deadline, and it did not work at first, so I added a Pre-Build event to run nuget.exe against the packages.config for each project.
TFS build service complains about that, so I am trying to get it working "right".
I have set the option in Visual Studio Tools menu.
I have installed NuGetEnablePackageRestore and run the fix.
I have verified that the packages directory is is source control, but is empty.
I have verified that the project files each include the following:
<RestorePackages>true</RestorePackages>
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
Building with Diagnostic level verbosity reveals that each project evaluates those properties, but the RestoreCommand in nuget.targets is never executed.
Any thoughts?
I have attempted to implement the solutions from these links:
nuget - package restore not working
NuGet Package Restore Not Working - I did post a question/comment on there asking for clarification...
http://nuget.codeplex.com/workitem/1879
Edit
Additionally, I have found that the RestoreCommand property is being evaluated during build. Diagnostic Verbosity shows:
RestoreCommand = (set EnableNuGetPackageRestore=true) && "C:\Source\Kiersted Direct And Related\Direct\Kiersted\.nuget\nuget.exe" install "packages.config" -source "#(PackageSource)" -o "C:\Source\Kiersted Direct And Related\Direct\Kiersted\packages"
I figured it out, and I found the answer here: MSBuild not running BuildDependsOn tasks from an imported project
The problem (after looking through the Diagnostic verbosity build output) was that the BuildDependsOn setting was getting un-set. My project files each had the import statement
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
but that statement was at the beginning of the XML tree. Apparently the import for Microsoft.CSharp.targets can interfere with that import and thus the BuildDependsOn.
My solution was to move the nuget.targets import to below the Microsoft.CSharp.targets import. Now everything builds beautifully.
This answer needs to be considered with the others. In my case, Visual Studio decided not to add the packages.config automatically into Source Control. Hence the file did not make it's way through to the build server for consideration during Nuget restore.