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
Related
I have a package which I added to to TFS feed, I can browse feed in VS 2K17, add the packge to add it to a dotnet project compile correctly and it downloads the pkg, on command line also msbuild t:restore works fine.
In TFS, I am using a
dotnet restore
step but it is failing with the following error for the same package
C:\Program Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error :
Unable to load the service index for source
http://vsalms:8080/tfs/TODOS/_packaging/e475f9ce-1afd-47c9-8aa6-2f0d54948126/nuget/v3/index.json.
[C:\agent_work\2\s\lib\CoreFlogger\CoreFlogger.csproj]
2018-12-03T14:24:46.6934510Z C:\Program
Files\dotnet\sdk\2.1.500\NuGet.targets(114,5): error : The token
supplied to the function is invalid
[C:\agent_work\2\s\lib\CoreFlogger\CoreFlogger.csproj]
I am not sure which version of nugget it uses as there is no indication in the task. I have downloaded nuget and added its path to the environment, typing nugget in console gives the following
NuGet Version: 4.8.1.5435 but when build fails, I see
Regarding dotnet version, on the commande line when I issue
dotnet.exe --version
2.1.500
In the build ouptut, I see
2018-12-03T14:24:38.9211043Z Description : Build, test, package, or
publish a dotnet application, or run a custom dotnet command. For
package commands, supports NuGet.org and authenticated feeds like
Package Management and MyGet. 2018-12-03T14:24:38.9211302Z Version :
2.131.0
On the TFS server, I also added a a key in global nuget.config as follows
What is missing? It seems that it is a connection issue but really not able to debug or find out wwhat/where to check
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 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.
I have F# project which I want to build with command line (to use that later in FAKE config).
The problem is that MSBuild fails to resolve assembly dependencies when I use it on the project file directly. While it goes fine when I use solution file with this single project included.
I really have run out of ideas. The solution file seems to not contain any critical information.
Another weird thing is that VSCode also fails to resolve one of those assemblies. I hope that when I fix MSBuild config I may be will able to see what's wrong with VSCode.
Command line:
"C:\Program Files (x86)\MSBuild\14.0\Bin\msbuild.exe" FSharpWeb1\FSharpWeb1.fsproj /t:rebuild
Error message:
C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj(173,5): error MSB4062: The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll. Could not load file or assembly 'file:///C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll' or one of its dependencies. The filename, directory name, or volume label syntax is incorrect. Confirm that the <UsingTask> declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.Done Building Project "C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\FSharpWeb1.fsproj" (rebuild target(s)) -- FAILED.
I've pushed the minimal demo to github: https://github.com/alehro/testMSBuild.git
It's actually easy to reproduce independently. In VS 2015 Community edition create new project from F# Web Template named "Web Api 2.2" and then try to build it with MSBuild.
Another disturbing thing is that the minimal demo produces different errors from those I've seen yesterday. Also vscode complains on different items. If yesterday it could not resolve a couple of calls, now it complains on all of:
open System.Net.Http
open System.Web
open System.Web.Http
open System.Web.Routing
telling that neither of them is defined.
Reformatting my comments to a response now that it's verified it works:
Your FSharpWeb1.fsproj references MSBuild.ExtensionPack.FileSystem.File task from MSBuild.Extension.Pack, but the path specified in the <UsingTask> tag contains $(SolutionDir) property which is not defined when you run MSBuild outside of Visual Studio.
The error message you're getting shows that in the highlighted part of the path:
The "MSBuild.ExtensionPack.FileSystem.File" task could not be loaded from the assembly C:\work\MNP\testMSBuild1\FSharpWebApi\FSharpWeb1\*Undefined*\packages\MSBuild.Extension.Pack.1.3.0\tools\net40\MSBuild.ExtensionPack.dll.
This can be remedied by conditionally setting the relative path when the property is not set by VS:
<SolutionDir Condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">..\</SolutionDir>
(original response for this solution: https://stackoverflow.com/a/33782131/1659828)
One more thing I mentioned in the comments is that this solution assumes you already have the necessary dependencies downloaded in the packages folder. Visual Studio does that automatically by restoring NuGet packages before build, but when you build in another context, you have to make sure the packages are restored, otherwise the build will keep failing.
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.