We recently moved up to TFS 2017 and I'm trying to get our existing builds transitioned from XAML based ones to the new build system. This is all behind the corporate firewall.
My test project (dotNet Core) was failing with the error...
Assets file '<snip>project.assets.json' not found. Run a NuGet package restore to generate this file.
...so I added a Nuget Restore step to the build. This resulted in the following error appearing in the build log...
<snip>
Starting: NuGet restore
**************************************************************************
==========================================================================
Task : NuGet Restore
Description : Restores NuGet packages in preparation for a Visual Studio
Build step.
Version : 1.0.1
Author : Microsoft Corporation
Help : [More Information](https://go.microsoft.com/fwlink/?
LinkID=613747)
==========================================================================
C:\Windows\system32\chcp.com 65001
Active code page: 65001
...waits here for 30 seconds...
connect ETIMEDOUT 117.18.232.200:443
**************************************************************************
Finishing: NuGet restore
<snip>
However, checking with both Fiddler and the network people, there is no (relevant) network activity from the box at the point that it waits about 30 seconds, at the point shown.
Clearly the Nuget Restore step is attempting to access the internet but is unable to due to it being unable to access the proxy (we had a similar issue initially setting up the build server) rather than it being blocked which would show in the network logs.
If I remote to the build server and login using the same credentials as the build service I can successfully use VS to build the test project on the box, but it is obviously using the IDE config file(s) to get to the proxy. I have configured the proxy in both the devenv.exe.config and the %appdata%\NuGet\NuGet.Config .
Can anyone suggest where else I can set it so that the Nuget Restore step can find it and use it, please?
Try the steps below on your build agent machine:
download the command line version of nuget
add it to the path env var
nuget.exe config -set http_proxy=http://proxy:port
nuget.exe config -set http_proxy.user=Domain\Username
nuget.exe config -set http_proxy.password=myPassword
Update:
The project.assets.json file maintains a project's dependency graph when using the PackageReference management format, which is used to make sure that all necessary packages are installed on the computer. Because this file is generated dynamically through package restore, it's typically not added to source control. As a result, this error occurs when building a project with a tool such as msbuild that does not automatically restore packages.
In this case, run msbuild /t:restore followed by msbuild, or use dotnet build (which restores packages automatically).
More details, please refer to the link below:
https://learn.microsoft.com/en-us/nuget/consume-packages/package-restore-troubleshooting
Related
I used NuGet to add CastleWindsor to a project. Eveything works ok.
When I check it into tfs, I get the following message.
Unable to find version '3.3.3' of package 'Castle.Core'.
Any idea how I can get the build server to get the new version of Castle.Core?
First just as Dave commented, please check if you have add the nuget install task in your build definition and before your build task.
Also make sure you are using the right version of Nuget. For example, if you already use V3.0 and the config file are still point to V2.0. You will get this error.
Moreover, double check if the packages can be restored successfully on you dev PC and build agent manually, you can also compare the nuget.config file on your TFS server and dev PCs to see if there is any difference between them. The nuget.config file locates at "%APPDATA%\NuGet\NuGet.Config".
TFS2012 does not restore the nuget packages automatically, you need to add a build step to call the nuget command to restore the nuget packages. Refer to this link for details: Package Restore with Team Foundation Build.
With TFS 2013 and later, packages are automatically restored by
default during build, provided that you're using a Team Build Template
for Team Foundation Server 2013 or later.
If you're using a previous version of build templates (such as in a
project that's been migrated from earlier versions of TFS), you'll
need to also migrate those build templates to TFS 2013. This
essentially means recreating the custom parts of the Build Templates
using the appropriate template for your source control (TFVC or Git).
For earlier version of TFS, you can simply include a build step to
invoke command-line restore as described earlier.
I have a solution containing multiple .Net Core projects, some of which are dependent on other projects in the same solution. The whole solution is hosted in a Git repository of an on-premises TFS server.
I want to set up an automated build process on the TFS server. For lack of better knowledge, I use the Visual Studio build template and leave all the settings on their defaults. When I run the build process, it fails on the "Build solution" step with the error message
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet\Microsoft.DotNet.Common.Targets(262,5): error : Project MyProject does not have a lock file.
Please run "dotnet restore" to generate a new lock file. [C:\TFSBuildAgent_work\6\s\MyProject\MyProject.xproj]
So I go ahead and create a PowerShell script with the content dotnet restore that I run before "Build solution" but after "Nuget restore". This also fails, this time on step "Dotnet restore" with the error message
Errors in C:\TFSBuildAgent_work\6\s\MyProject\project.json
Unable to resolve 'ProjectDependency (>= 1.0.0)' for '.NETFramework,Version=v4.6.1'.
When I run dotnet restore on my local machine, it completes without any issues.
Any help or hints are greatly appreciated!
I helped myself now in packaging the project dependency and uploading it to my inhouse package server. dotnet restore will then pull it from the server and build the whole project. Not the nicest way, but at least it's working.
When I tried to use Jenkins as our CI environment to build ASP.NET MVC5 project, I set up to use MSBuild.exe to build project.
But when the cmd run into restore nuget packages, it stucked. The error message is as below:
WARNING: Unable to connect to the remote server
Unable to find version '3.4.1.9004' of package 'Antlr'.
Build step 'Execute Windows batch command' marked build as failure
But if I use windows command line to run the msbuild, it is working and could download the pkg from nuget.org. Error only happened when try to build in Jenkins. And my network is fine, but behind a company proxy/firewall, I am not sure what it is. And I have set to auto restore nuget package in VS2013.
Any idea is much more appreciated.
I finally found out the root cause, it is the Jenkins service has not enough access right. Open windows services and right click on the Jenkins service, in the security tab, change the default user to whom that has enough access right to the Internet.
I am attempting to fully automate the deployment of a simple assembly onto two application servers (which have the Tentacle services installed), and I'm running into a few challenges.
What I have achieved:
I can create a NuGet package with /p:RunOctoPack=true.
I can manually upload (publish?) the package to my built-in feed on the Octopus Deploy server.
I can deploy the packages to both my application servers using the Octopus Deploy portal.
I can infer from the post (OctopusPublishPackageToHttp in TFS Service) that I should be able simply put all of the following on the Process/Build/Advanced/MSBuild Arguments box
/p:RunOctoPack=true
/p:OctopusPublishPackageToHttp=http://octoserver:8081/nuget/packages
/p:OctopusPublishApiKey=API-MYKEY.
However my builds are returning the error
Exception Message: Access to the path 'C:\Builds\1\Experiments\CIBuildDef\bin\ConsoleTibcoMefClient1.1.0.0.0.nupkg' is denied.
(type UnauthorizedAccessException)
With this assembly (a simple .NET Class Library). The builds are all being dropped into the same path (C:\Builds\1\Experiments\CIBuildDef\bin). I'm accustomed to a new folder being created by the build every time. I must be missing something in the build definition settings. Am I getting this error because I'm not changing the version number of the package yet? I cannot seem to delete the nupkg that was originally dropped in the Builds directory, even after deleting it from the feed.
How do put my NuGet package onto the feed with TFS?
How do run my Octopus Deploy steps from TFS?
Am I asking the right questions?
Thanks for any input you can provide.
Could you ping your octopus server from tfs build server? And could you telnet to 8081 port from your tfs build server? If you could, you should rebuild the project not build for the same repository. If the new nuget version is not higher than 1.0.0.0 octopack could fail. You must increment the nuget version from your tfs build template. The following commands must be work for you. This commands are for msdeploy deployment with powershell. If you want to use msdeploy you must install it to tentacles. I am using it for web project deployment.
Command line arguments:
/t:Rebuild /p:AutoParameterizationWebConfigConnectionStrings=False
/p:DebugSymbols=false /p:DebugType=None /p:IsAutoBuild=True
/p:CreatePackageOnPublish=true /p:Configuration=Release;DeployOnBuild=True;PackageLocation=".\obj\Release\Myproject.zip";PackageAsSingleFile=True /p:RunOctoPack=true
/p:OctoPackPackageVersion=%VERSION%-dev
/p:OctoPackPublishPackageToHttp=http://octopus.yourdomain.com/nuget/packages /p:OctoPackPublishApiKey=API-xxxxxxxxxxxxx
Trying to run NuGet.exe pack on a .csproj with a .nuspec file.
Everything works fine locally. I've got NuGet.exe checked in alongside the sources. This particular NuGet package does not have any dependencies on any other NuGet package listed in the .nuspec file (and even if it did, they would be available in source control). I expected for NuGet.exe to just run on the build machine without trying to interact with anything on the web.
There is a NuGet.config file checked into the root folder of the source tree, but the command line commands run on the build machine appear to be ignoring it. The version appears to be 2.6.40619.9041 (on my local machine, the same nuget.exe that is checked into version control).
On the build machine, it was initially failing with the "consent" error, below:
Package restore is disabled by default. To give consent, open the Visual Studio Options dialog, click on Package Manager node and check 'Allow NuGet to download missing packages during build.' You can also give consent by setting the environment variable 'EnableNuGetPackageRestore' to 'true'.
This seemed odd because in this particular example, there are no packages to restore. I'm trying to build a package that does not have any other package dependencies. To get past this error, I started running it (in MSBuild Exec task) by forcing the EnableNuGetPackageRestore environment variable, like this:
Command="(set EnableNuGetPackageRestore=true) & $(NuGetExe) pack $(NuGetSpecFile) $(NuGetPackArgs)"
The next error from the build machine build log, after getting past the consent issue, is this:
A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond 168.62.224.25:443
That IP address is the address for nuget.org.
It appears as though nuget.exe is trying to do something like auto-update itself or some other task.
Q1: Is there any way to disable this behavior? If it is the auto-update, can I prevent this with some sort of command line option.
Q2: Although the nuget docs site lists -ConfigFile as a valid parameter for "nuget pack" it won't accept it. Is that parameter supposed to work?
Q3: If all else fails, how do I get NuGet.exe to look at our internal ProGet server (to which it could have access) instead of trying to look at nuget.org (to which access is blocked)?
Umm, I had checked in the NuGet.exe "bootstrapper" instead of the actual program.
Once I checked in the version found at %LOCALAPPDATA%\NuGet it stopped trying to reach out to the web.