I have a solution building as part of continuous integration, with a step to push a class library out to my VSTS package feed. This worked the first time the CI build ran and created the package. The second time it shows it was successful, but a new version doesn't exist or any sign of a new package.
Prior to the second build, I promoted the package to #release, if that makes a difference?
Output of the CI build for NuGet push is below:
2017-07-24T10:48:51.4888942Z ##[section]Starting: NuGet push
2017-07-24T10:48:51.4888942Z ==============================================================================
2017-07-24T10:48:51.4888942Z Task : NuGet
2017-07-24T10:48:51.4888942Z Description : Restore, pack, or push NuGet packages, or run a NuGet command. Supports NuGet.org and authenticated feeds like Package Management and MyGet.
2017-07-24T10:48:51.4888942Z Version : 2.0.5
2017-07-24T10:48:51.4888942Z Author : Microsoft Corporation
2017-07-24T10:48:51.4888942Z Help : [More Information](https://go.microsoft.com/fwlink/?LinkID=613747)
2017-07-24T10:48:51.4888942Z ==============================================================================
2017-07-24T10:48:51.9019022Z [command]C:\Windows\system32\chcp.com 65001
2017-07-24T10:48:51.9059034Z Active code page: 65001
2017-07-24T10:48:51.9219032Z SYSTEMVSSCONNECTION exists true
2017-07-24T10:48:51.9409032Z Detected NuGet version 4.0.0.2283 / 4.0.0
2017-07-24T10:48:52.1389068Z Saving NuGet.config to a temporary config file.
2017-07-24T10:48:52.1449080Z ##[warning]No package sources were found in the NuGet.config file at d:\a\1\Nuget\tempNuGet_150.config
2017-07-24T10:48:52.1549071Z [command]d:\a\_tasks\NuGetCommand_333b11bd-d341-40d9-afcf-b32d5ce6f23b\2.0.5\VstsNuGetPush\0.13.0\VstsNuGetPush.exe d:\a\1\a\WAGR2.DAL.1.0.0-CI-20170724-104834.nupkg -Source https://forgan.pkgs.visualstudio.com/_packaging/1b92b113-5d65-4b30-8749-9362924199b5/nuget/v3/index.json -AccessToken ******** -NonInteractive -Verbosity Detailed
2017-07-24T10:48:52.7149186Z Trying to authenticate with auth token.
2017-07-24T10:48:53.3099300Z Successfully authenticated.
2017-07-24T10:48:53.3189305Z Authentication and request took 00:00:01.0127956
2017-07-24T10:48:53.3589311Z Adding package WAGR2.DAL.1.0.0-CI-20170724-104834.nupkg to feed 1b92b113-5d65-4b30-8749-9362924199b5 on https://forgan.pkgs.visualstudio.com/.
2017-07-24T10:48:53.3589311Z Trying to add package to feed without uploading.
2017-07-24T10:48:53.3589311Z Adding package to feed.
2017-07-24T10:48:54.1399458Z The package content is not already on the service.
2017-07-24T10:48:54.1399458Z Uploading package content.
2017-07-24T10:48:56.0287785Z Done uploading package content.
2017-07-24T10:48:56.0287785Z Adding package to feed.
2017-07-24T10:48:57.3686297Z Successfully added package to feed.
2017-07-24T10:48:57.4256306Z ##[section]Finishing: NuGet push
UPDATE
The Nuget Pack option was to use automatic package versioning based on date & time.
The package doesn't appear in the NuGet gallery along side the others, which is also odd.
I don't know why this was happening, but what now works is:
Remove package from feed
Change the Nuget Pack Automatic package versioning from date & time to build number, using the Build Number Format (under Options): '$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)'
On NuGet Push, I also had to check the box Allow duplicates to be skipped
Packages now publish every time and also appear in the NuGet gallery.
It seems you have publish the package WAGR2.DAL.1.0.0-CI-20170724-104834.nupkg successful to your VSTS feed. So please find the package with below steps：
In you VSTS feed, set Release view to All.
Find the package WAGR2.DAL and click it.
If you have the package version as WAGR2.DAL.1.0.0, it will be treated as the latest version. And you can find the version 1.0.0-CI-20170724-104834 in drop down list.
Related
So I have an Azure Artifacts feed. This feed has some packages. One if it is Newtonsoft.Json lets say 10.0.4 version. The feed is set up with an upstream source for Nuget.
When I add this feed to my project, my expectation is that when I want to get NewtonSoft latest, I would be able to get it. However, in Visual Studio or Nuget Restore, it fails to see any other version. The only version it can see is 10.0.4. I am expecting that since I specified an upstream source, it would get the packages from upstream.
I tried unlisting the 10.0.4 version, now it says newton soft is not even found.
What am I missing? What could be going on here?
For me that was a problem with permissions to the Azure Artifacts package repo.
If you are part of a group which has "Reader" access to the Azure Artifacts package repository, your nuget restores or npm installs (for JavaScript packages) WILL NOT be able to add packages to the Azure Artifacts package repository mirror/proxy.
Set the permissions of your teams/people with access to the Azure Artifacts package repository one level higher than "Reader" - set them to "Collaborator":
This is an error that's easy to miss since if you are the Artifacts package repo creator, you won't get any access errors other people might be having because you're the owner of the repo (in the picture below I'm Artur)
Once you've enabled an upstream source, any user connected to your feed can install a package from the remote feed, and your feed will save a copy.
If you add your Artifacts feed in the Package sources in Visual Studio. When you search for package NewtonSoft within your artifact feed in Visual Studio. It is the default behavior that you can only see the saved copy of package NewtonSoft.
To install the NewtonSoft latest, you can search and install it in the nuget.org package source(You need to add nuget.org to Package sources if it is not listed in the package source list )
Or you can use command line to install the NewtonSoft latest by specifying the version parameter. See below:
Install-Package Newtonsoft.Json -Version 12.0.3
You can also directly add NewtonSoft latest version as package dependency to your project by editting .csproj or package.config file. When you restore your packages. if the NewtonSoft latest is not found in your Artifacts feed, it will be downloaded from the upstream source.
This question already has an answer here:
How to test new Azure DevOps extension version before publishing it for everyone
(1 answer)
Closed 3 years ago.
I want to take the package as-built by the release line, and install it to another (non-prod) VSTS, so I can validate it works, before installing to our prod VSTS.
We use VSTS vNext build with VSTS task 'Package Extension' to compile the package.
This compiles 'Publisher' with value 'my-prod-publisher' into file 'extension.vsixmanifest'
I've tried:
Manually upload package to VSTS marketplace portal for "my-dev-publisher".
Results are:
'Upload Error' :
Publisher ID 'my-prod-publisher' provided in the extension manifest
should match the publisher ID 'my-dev-publisher' under which you are
trying to publish this extension.
Modify VSIX package:
Unzip the .VSIX package
Edit file 'extension.vsixmanifest' to change 'Publisher' from value 'my-prod-publisher' to 'my-dev-publisher'
zip contents into new ZIP file
change package file suffix .ZIP to .VSIX
upload to VSTS marketplace portal for 'my-dev-publisher'
Results are:
TF400898: An Internal Error Occurred. Activity Id: 64d37121-ea19-42dc-9994-dbef8e6dc205.
My google-fu failed to find content about this error relevant to my case. Didn't search too hard on this, as I wasn't expecting re-zipping the files to produce same results as how these packages are compiled.
Publish via tfx-cli
tfx extension publish --service-url https://marketplace.visualstudio.com/ --publisher "my-dev-publisher" --vsix .\my-prod-publisher.vsts-buildrelease-tasks-0.6.181012.vsix --accounts my-dev-vsts --auth-type pat --token [my-dev-vsts-PAT] --trace-level debug
Results in error:
Received response 401 (Not Authorized).
Check that your personal access token is correct and hasn't expired.
I verified 'my dev vsts PAT' isn't expired, and is authorized for "All scopes", in VSTS 'my-dev-vsts'.
Validating a branch build, instead of release-line build
Compiling the package with 'Publisher' = 'my-dev-publisher' does allow me to publish to portal 'my-dev-publisher' which then allows me to install extensions package into 'my-dev-VSTS'.
This wasn't effective enough, since I've been burned by subtle issues such as:
package/tasks version numbers not getting bumped correctly, or different values from PROD.
files/changes missed during commit to release-line.
We have support for these features in the CI/CD tasks for extensions. These build tasks also offer the option of bumping the version of the extension and the build tasks included in the extension. You can standardize the build process using a Task Group if you want to. Or use Release Management to promote the vsix from dev to prod. These tasks will actually override the publisher-id. You will also have to override the extension-id and make it private. Only one public prod extension can be made public and extension-ids are globally unique.
The alternative is to build the dev and the release vsix at the same time to ensure they're matching. Then don't use the release package until you need it.
The issues you're seeing are the reason we built these tasks.
TF400898: An Internal Error Occurred. Activity Id: 64d37121-ea19-42dc-9994-dbef8e6dc205. This happens when the zip is using the wrong compression method. In the extension tasks I had to fiddle quite a bit to get the 7z syntx right.
Received response 401 (Not Authorized). Check that your personal access token is correct and hasn't expired. is caused by the fact that when publishing from vsix the --extension-id and --publisher are ignored. But TFX doesn't tell you.
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
I have setup a NuGet Package feed in TFS 2017 Update 1.
The NuGet Source is as following
http://tfsserver:8080/tfs/defaultcollection/_packaging/NuGet-Feed/nuget/v3/index.json
Following the instructions stated when connecting to TFS Package Feed, I added NuGet source locally and also try to publish package(s) to the NuGet Feed with following format as an example:
nuget.exe push -Source "NuGet-Feed" -ApiKey INCTX Microsoft.AspNetCore.Http.Abstractions.1.1.2.nupkg
The result of executing above command is as following:
Pushing Microsoft.AspNetCore.Http.Abstractions.1.1.2.nupkg to 'http://tfsserver:8080/tfs/DefaultCollection/_packaging/23093bd8-41aa-403d-9d3f-5c713b14ce32/nug
et/v2/'...
PUT http://mtrlpqdc2av-053:8080/tfs/DefaultCollection/_packaging/23093bd8-41aa-403d-9d3f-5c713b14ce32/nuget/v2/
Accepted http://mtrlpqdc2av-053:8080/tfs/DefaultCollection/_packaging/23093bd8-41aa-403d-9d3f-5c713b14ce32/nuget/v2/ 1702ms
Your package was pushed.
As it shows, the package is published to 'nuget/v2' endpoint.
Running TFS Build with NuGet Restore task: the following command expects
nuget/V3/ endpoint from the TFS Feed which does not exists.
Note: NuGet restore task in TFS build is customized to use NuGet 4.. version.
GET http://tfsserver:8080/tfs/DefaultCollection/_packaging/23093bd8-41aa-403d-9d3f-5c713b14ce32/nuget/v3/flat2/microsoft.aspnetcore.http.abstractions/1.1.2/microsoft.aspnetcore.http.abstractions.1.1.2.nupkg
The question I guess is why NuGet Push will publish to 'nuget/v2/' endpoint.
TFS Build NuGet Restore Task output:
2017-07-06T15:58:13.0657118Z CredentialProvider.TeamBuild: URI: http://tfsserver:8080/tfs/defaultcollection/_packaging/INCTX-NuGet-Feed/nuget/v3/index.json
2017-07-06T15:58:13.0657118Z CredentialProvider.TeamBuild: Is retry: False
2017-07-06T15:58:13.0657118Z CredentialProvider.TeamBuild: Matched prefix:
2017-07-06T15:58:13.2688422Z CredentialProvider.TeamBuild: This provider only
handles URIs from the build's Team Project Collection
2017-07-06T15:58:13.6125991Z GET tfsserver:8080/tfs/DefaultCollection/_packaging/23093bd8-41aa-403d-9d3f-5c713b14ce32/nuget/v3/flat2/microsoft.netcore.app/index.json
2017-07-06T15:58:13.6125991Z GET tfsserver:8080/tfs/DefaultCollection/_packaging/23093bd8-41aa-403d-9d3f-5c713b14ce32/nuget/v3/flat2/microsoft.netcore.app/index.json
2017-07-06T15:58:13.7219799Z NotFound
Thanks,
Mamrez
You may want to check your nuget.config and reference the following:
https://learn.microsoft.com/en-us/nuget/tools/nuget-exe-cli-reference#push
it says you can either specify it on push or define DefaultPushSource in the config. I might suspect your v2 source is defined as DefaultPushSource in the config.
try: nuget.exe config DefaultPushSource to see what it is set to.
Running on the TFS App-Tier through command line also issued an error which stated the NuGet source couldn't be reached.
Finally figured out that which NuGet.config file was being used and as the result, the NuGet publish from TFS start working both on App Tier and in the TFS build.
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.