I updated the Target Framework of all the Projects in my solution from 5.0 to 6.0.
I also had to Upgrade the Target Framework of 2 dependency NuGet packages that I own which are imported from a Releases source in Azure.
After doing this, and adding a step in the Build pipeline to load the correct version of the SDK, I started getting the following error repeated for every project when a step tries to build and run the tests:
F:\BuildAgents\_work\286\s\[Proj Name]\[Proj Name] : error NU1301: Unable to load the service index for source https://pkgs.dev.azure.com/[redacted]/_packaging/Releases/nuget/v3/index.json.
Failed to restore F:\BuildAgents\_work\286\s\[Proj Name]\ [Proj Name] (in 18.5 sec).
Does anyone know what could be causing this? The error code suggests the source is not available but the build step prior successfully adds the source!
The NuGet source:
The updated dependency artifacts which I believe the source uses:
The Pipeline:
The BUILD step BEFORE the error:
This turned out to be some sort of authentication error for the NuGet source.
Why? No idea. The password being stored was correct.
The fix was deleting the password variables in Azure and re-adding them from scratch for each pipeline.
Related
I have a project which has Entity Framework version 4.6.4 installed. The relevant line from the packages.config folder shows:
<package id="EntityFramework" version="6.4.4" targetFramework="net47" />
If I do a clean and build the project rebuilds with zero issues.
However if I run a devops build pipeline as follows:
The process falls over with an error stating that
The type or namespace name 'Core' does not exist in the namespace 'System.Data.Entity'
To the best of my knowledge all of the build errors seem to be related to Entity Framework and the Nuget Restore step prior to the build step seems to show packages being restored successfully.
Any pointers would be much appreciated.
Hi i'm a newbie to azure devops CID and pipelining.
the azure devops is on premise, my pipeline looks as below however it fails at nuget pack command (2nd from bottom)
the error i get is ##[error]The nuget command failed with exit code(1) and error(Error NU5012: Unable to find 'C:\AzureDevOpsAgents\Agent#1_work\4\s\Code\MyCompany.Core\bin\release\net472\MyCompany.Core.dll'. Make sure the project has been built.
I went into the azure agents directory and the dll is located C:\AzureDevOpsAgents\Agent#1_work\4\s\Code\MyCompany.Core\bin\x64\Release\net472\MyCompany.Core.dll
the difference being the x64, so how i can i get nuget pack to take into consideration the architecture as part of the pack path
variables
ok i as usual every time i post a question on here, despite struggling for hours i manage to solve it.
I've added $(BuildPlatform)\ in front of the default $(BuildConfiguration) for the configuration to package and i can see a package in the location
I'm new to Azure DevOps (VSTS) and I'm attempting to set up a new Pipeline build using the Artifactory Maven build step. When running the build I get the following error:
2018-09-12T20:59:02.0861829Z ##[error]Error: Command failed: D:\a_jfrog\1.19.1\jfrog.exe rt mvn "install -f D:\a\1\s\pom.xml" D:\a\1\s\config --build-name="SomeProject-Maven-CI" --build-number="20180912.6"
2018-09-12T20:59:02.0988256Z [Error] Wrong number of arguments. You can read the documentation at https://www.jfrog.com/confluence/display/CLI/JFrog+CLI
I found this info on GitHub: https://github.com/jfrog/jfrog-cli-go/issues/165
Its a similar error but not quite the same. I'm not sure how to edit the command that Azure Pipeline is running or even if I can.
I figured out my issue. I had a space included in my build name and it apparently the JFrog Cli didn't like that. When I removed the space the error went away. Other errors came up but that's off-topic from this question.
Can you please report the errors your encountered in Artifactory VSTS extension's GitHub repository?
We'll really appreciate it.
Update: A pull request opened to target this issue. You can track it here.
Update 2: Fixed in latest release 1.4.0.
I am starting to delve into Octopus Deploy and setting up my first deployment but I've ran into a bit of a snag. I have tried to be as specific as possible in lieu of finding someone who has experienced this same problem more recently. "This is not a new problem. See -reseach"
The setup
Versions:
TeamCity 10.0.4
Octopus Deploy 3.10.1
My continuous integration stack is comprised of TFS, TeamCity and now Octopus. My deployment process:
TeamCity runs the .NET application build. (Scripts, tests, etc..)
TeamCity Octopus plugin successfully creates the versioned Nuget packages.
A TeamCity build step using "OctopusDeploy: Push packages" pushes the packages to the octopus server.
In Octopus an external feed was added an tested called "Octopus Local Packages" pointing to the default internal octopus package directory: C:\Octopus\Packages.
An octopus project was created with a single step using the "Deploy an IIS Web Site" template, where the package section is setup like this:
The problem
Research
This has happened in the past on versions prior to 3.0.7 where it was fixed. Link to bug thread 1.
Then it started happening again at some point prior to version 3.4.15 where it was fixed. Link to bug thread 2.
Any help, fix, or workaround will be greatly appropriated. If there is a detail that I'm missing I will be more than happy to clarify.
Update
This may very well be a rookie mistake when it comes to Octopus. The error shown in the question is in fact a result of the deployment package not being found. The following are findings through documentation and trial an error:
Octopus Server (built in) is a push feed only. Meaning that packages can be uploaded to this feed but not consumed.
To consume Octopus' server local packages, namely the packages previously pushed to Octopus Server (built in) from say TeamCity, you have to serve those packages yourself.
You can server those packages through Octopus by creating an external feed that points to the server's package default path: C:\Octopus\Packages
Most Importanly, and the fix to the error!
When changes are made to a deployment process step, a new release MUST BE created. Simply redeploying the previous release will try to redeploy with the previous step settings saved in a snapshot and not with the new step settings. This may come a a surprise to TeamCity users like myself based on TeamCity's behaviour.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.