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.
Related
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
Visual Studio 2017 Enterprise
ASP.NET MVC Application
TypeScript 2.5 SDK
Source control is in TFS
I am using Microsofts built in property editor instead of a custom tsconfig.config file:
To allow an easy workflow I am using Mad's Kristensen's Package Installer to do my NPM installations of Definitively Typed TypeScript definitions within my MVC web project.
Ultimately this ends up creating node_modules in a folder under the solution path:
While I could use this SO post to do a GLOBAL install using -g --prefix so that I could place this into a folder of my choosing say:
MVCProjectFolder\TypeScript\Npm\Modules
I have some concerns or at least a request for a better way.
So my questions are:
Is there a different way to changing the node_modules folder from within Visual Studio without specifying -g -prefix
What is the best approach to bundle all the TS generated JavaScript in the project? (The TypeScript Build property option "Compile JavaScript output into file" appears to have no effect)
Do I only need to include the d.ts tiles in TFS so that the following will keep on working when synced?
--
/// <reference path="../../node_modules/#types/jquery/index.d.ts" />
/// <reference path="../../node_modules/#types/handlebars/index.d.ts" />
Answer your TFS part, you don't need to check in node_modules folder to TFS. When you want to build your project in TFS, add a nmp task in your build definition:
https://learn.microsoft.com/en-us/vsts/build-release/tasks/package/npm
I followed the instructions in the answer by smoothdeveloper in How to use paket from command line and now I have all three Paket directories in my solution. However, I cannot add packages either from the command line or from VS 2017.
I tried to add XUnit from the command line. A line with nuget xunit appeared in the paket.dependencies file. But there is no xunit line in the paket.references file. If I add open XUnit or any variation (Intellisense does not show anything starting with xu) to my code in the editor I get a red squiggly line.
So I tried to add XUnit from the solution explorer. Right-clicking on something (I tried several places) I should get an Add package menu item. But no such item shows up.
I must have done something wrong, but I cannot figure it out. Any help?
(Also, perhaps related, if I click on the Download button in https://marketplace.visualstudio.com/items?itemName=SteffenForkmann.PaketforVisualStudio nothing happens.)
There are two ways to add packages to individual projects from the command line with Paket using parameters for paket add (as documented in https://fsprojects.github.io/Paket/paket-add.html):
-p <path> (or --project <path>) to install into one specific project
-i (or --interactive) to be asked for each project in the solution whether to reference the package
FWIW, I also had no problems adding a package from the Visual Studio integration; you could try un- and reinstalling the extension, maybe there's some wrong configuration setting that can be fixed that way.
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'm trying to configure an automated build of a project that has a NuGet package reference, but I'm not having any luck. (FYI I'm still pretty wet behind the ears with all of this, so please provide simple steps and/or configurations.)
Note: this isn't a duplicate of other similar questions, as I'm using a central package repository. Other similar questions make no mention of this important detail, so they should be assumed to not be relevant.
The build runs fine without the reference. I added Newtonsoft.Json and bound to it by including this simple construct:
Dim eHandling As Newtonsoft.Json.ConstructorHandling
eHandling = Newtonsoft.Json.ConstructorHandling.Default
I checked it in and the build started, but NuGet hadn't first copied the assembly to my application's bin folder. It did, however, copy it to here:
Restoring NuGet package Newtonsoft.Json.9.0.1.
Adding package 'Newtonsoft.Json.9.0.1' to folder 'C:\Agent\_work\1\s\packages'
Naturally the build failed, as it couldn't find the dependency.
It's worth noting that I'm using a central package repository on my dev machine:
<config>
<add key="repositoryPath" value="D:\Dev\Packages" />
</config>
I'd like to emulate this behavior on the server as well, e.g. C:\Packages\*\*.nupkg.
I tried using the standard %AppData%\NuGet\NuGet.config file, but the build ignores it. I tried the advice in this answer (using repositoryPath instead of packageSources as shown there), but that causes the server to hang until I restart the VSO Agent service. Thinking it might be a permissions issue, I reconfigured the agent to run under the user account associated with the %AppData% location of NuGet.config. Still no luck. No build.
How can I get NuGet to download and populate the central package repository on the server and then copy the appropriate dependencies to the application bin folder prior to running the build step?
EDIT 1
Update: Apparently something's working, as I now have a C:\Packages\Newtonsoft.Json.9.0.1 folder on the server. However, the assembly still isn't being copied to the application bin folder prior to build. Same result. Failed build.
EDIT 2
OK, I'm getting closer. I created a D: drive on the server and set the local repositoryPath value to D:\Dev\Packages, the same as it is on my dev machine. The build is still failing, but a quick look at the project XML reveals this:
<Reference Include="Newtonsoft.Json, Version=9.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed, processorArchitecture=MSIL">
<HintPath>..\..\..\Packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll</HintPath>
<Private>True</Private>
</Reference>
How to deal with that relative path? That should fix it, yes?
EDIT 3
OK, that worked. I edited the project and changed HintPath to
D:\Dev\Packages\Newtonsoft.Json.9.0.1\lib\net45\Newtonsoft.Json.dll
I now have a successful build.
But this is going to get real tedious real fast. Surely I'm not going to have to do this for every single NuGet reference in every single project, past present and future... am I?
OK, got it.
As long as the repositoryPath folder on the server is the same number of levels deep as on our dev machine—in relation to the folder in which the Build Agent puts the project file—we can put it anywhere we want and retain the relative HintPath value in the project file.
For example, in my case I ended up setting the server location to C:\Agent\Build\Packages, to match the hierarchical location of the local Git repos on my dev machine:
D:\Dev\Packages
D:\Dev\Git\app.repo\App\App.vbproj
Works great.
EDIT
Just to clarify, the action of copying the assembly from the package folder to the application bin folder isn't a NuGet action. It's an MsBuild action (i.e. the CopyLocal setting in the project's assembly reference properties).
The reason it was failing was that MsBuild couldn't find the assembly to copy, according to its relative reference as specified in the project file.
So technically my question title is incorrect. The NuGet Installer step has been working fine all along.