I'm trying to restore a NuGet package from an Azure Devops Artifact to my local installation as part of a gulpfile script.
However, I'm getting a
Response status code does not indicate success: 401 (Unauthorized).
with:
Unable to load the service index for source https://my-visualstudio-dot-com-npm-feed-here
I've tried creating a nugetauth.npmrc file with the following content:
registry=https://my-visualstudio-dot-com-npm-feed-here
always-auth=true
I then run:
vsts-npm-auth -config nugetauth.npmrc
to generate my new .npmrc file, which I then place in the same directory as my package.json and gulpfile.js files.
When I subsequently run my 'Nuget-restore' task from task runner (with "gulp-nuget-restore": "^0.7.0"), it's failing to authenticate to my feed. What am I missing?
If you want install NuGet package from azure devops artifacts, you should add a nuget.config file to your project, in the same folder as your .csproj or .sln file. Please check this document for more information. Then you can use nuget restore task
If it is a npm package, you should use npm install task.
If you are using the feed from azure devops pipeline. You also need to check if your project build service account have the reader permission to this feed. Please check below steps.
Click the Feed Setting(the gear icon)--> go to Permissions --> Check if group {projectName} build service(OrganizationName) has the permission(Click add groups to add your project build service account if not already existed).
Please refer to 'npm' task in ADO - https://learn.microsoft.com/en-us/azure/devops/pipelines/tasks/package/npm?view=azure-devops to install and publish npm packages. Hope this helps
We actually found two ways of resolving this in the end.
One was to use the gulp-nuget task instead, to download a specific version of Nuget.exe (5.0.2) which would then allow us to subsequently run the restore (as I believe that version of Nuget uses the credential provider by default).
The other (which we ended up going with) was to add
overrideParams.push('/p:NuGetInteractive=true')
to the msbuild task. This will prompt users to log in if not authenticated.
Related
Build pipeline failed for below DownloadPipelineArtifact#2 task in my VB.Net App Deployment.
##[error]No builds currently exist in the pipeline definition supplied.
Code for DownloadPipelineArtifact#2 task in azure-pipelines.yml file is displayed as seen below:
Requesting assistance on the same.
That task fails because you havent published an artifact with that pipeline.
you have 2 different ways to publish artifacts:
publish build artifacts (deprecated) used mostly in classic pipelines
can only be downloaded with download build artifact step
publish pipeline artifacts are used to publish an artifiact available for this same build or another pipeline
can only be downloaded from a download pipeline activity
You need to publish your build using publish pipeline artifact first (check if not already).
So first check the source pipelien with definition 370 from Project StarsDemo, and see if the latest build published an artifact or had an issue.
Also, per documentation, the runId is required (aka pipelineId, buildId).
I was able to resolve the issue by changing runVersion value to latest instead of latestFromBranch , after which the pipeline build successfully.
I am beginner to A and just starting to work in it
What task I must add in project ASP.NET CORE to Azure DevOps Pipelines to pass the build number from the azure devops pipeline to the project code
Client.Shell.csproj:
<MinimumRequiredVersion> 4.60.0825.700 </MinimumRequiredVersion>
<ApplicationRevision> 716 </ApplicationRevision>
<ApplicationVersion> 4.60.0825.% 2a </ApplicationVersion>
https://i.stack.imgur.com/BXyHm.png
You can do something like this, Replace "1.2.3" with your build parameter.
dotnet publish ./MyProject.csproj /p:Version="1.2.3" /p:InformationalVersion="1.2.3-qa"
Look at this https://github.com/dotnet/docs/issues/7568
When a pipeline runs, it usually performs get sources action first. So you just need to map the correct project path, then the pipeline will get entire project to the Agent's working folder.
To update the version in .csproj file, and to pass the build number from the azure devops pipeline, you can check Assembly Info extension, and use the variable $(Build.BuildNumber) in the version field.
This extension can update project AssemblyInfo files and .Net Core / .Net Standard project files .csproj. For detailed instructions on how to configure the extension please see the following link:
https://github.com/BMuuN/vsts-assemblyinfo-task/wiki/Versioning
If you want to update the file in repo, you still need to run git push command to push the changes to the repo.
I am trying to run the "Visual studio build task" in VSTS CI, but its failing with the following error:
Build error
I read it here bclbuildWhat does the Microsoft.Bcl.Build NuGet package do?
and passed the MSBuild arguments as /p:BclBuildImported=Ignore but still it complains that nuget restore didn't occur. What could be the problem?
Nuget restore task:
Nuget-restore task
Firstly make sure you can build the project locally with VS. Then add Nuget Restore task in the build definition to restore the packages.
UPDATE:
Just check your Nuget.config file, make sure you have set the correct feeds/package sources you want to consume and the package Microsoft.Bcl.Build.1.0.21 is included in the sources.
See Specifying sources in NuGet.config for details.
Besides, you can also try to create a new build definition with the Nuget restore task, then provide the nuget.config file and proper path to solution, also try with other Hosted agents.
I am using VSTS to build a xproj(dnx), the output is a set of a.nupkg with a.symbols.nupkg.
When i run the publish nuget package task it tries to upload all *.nupkg files to VSTS package managment. So when ever it hits the first symbols package it gets a 409 Conflict error.
In my dev builds i have a script that creates the package version by appending "alpha-{buildnumber} at the end, so as an example it would look like this: 1.0.0-alpha-1
So my question is, how is the best way to handle the symbols packages?
I manage to make it work by appending -:**\\*.symbols.nupkg to the default pattern in the VSTS Task.
I am trying to use MSDeploy to deploy an MVC project to the server using TeamCity. When I do this on my computer in powershell, using the following command:
msbuild.exe .\mvc.csproj /p:PublishProfile=DevServer /p:VisualStudioVersion=11.0
/p:DeployOnBuild=True /p:Password=MyPassword /p:AllowUntrustedCertificate=true
It builds the project and deploys it to the server (info defined in the DevServer publish profile) perfectly. The output shows an MSDeployPublish section at the end, in which I see text like Starting Web deployment task from source... and then with rows telling me what files are updated, etc.
When I run this on TeamCity, using an MSBuild Build step, on the same file, with the same parameters (from the same working directory) it builds the project but does not publish it. Instead it has the regular output from a build process (CoreCompile, _CopyFilesMarkedCopyLocal, GetCopyToOutputDirectoryItems, CopyFilesToOutputDirectory) but then does not actually go and publish anything.
What changes to I need to make to the setup in TeamCity to get it to publish deploy in the same way that it works using MSBuild from my computer?
(TeamCity 7.1, MSBuild 4.0, WebDeploy 3.0, Visual Studio 12, IIS 7. Related to my previous question)
We do our WebDeploys with a TeamCity MSBuild step configured as follows:
Build File Path: Server.csproj
Command Line Parameters:
/p:Configuration=%configuration%
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=https://%web.deploy.server%:8172/MsDeploy.axd
/p:DeployIisAppPath=%web.deploy.site%
/p:AllowUntrustedCertificate=True
/p:Username=
/p:AuthType=NTLM
We use integrated authentication; change as necessary to fit your scheme. The value of this, I think, is that it builds everything from scratch and doesn't rely on a pre-built package. From the gist you posted I noticed that you do some DB publishing, we don't use WebDeploy for that so I can't offer any guidance there. Hope this helps.
I use MSBuild.exe to package to zip, and MSdeploy.exe to deploy in separate steps.
To deploy the package.zip file on the command line:
"C:\Program Files\IIS\Microsoft Web Deploy V2\msdeploy.exe" -verb:sync
-source:package="C:\Build\MyAppName.Debug.zip"
-dest:auto,wmsvc=webservername,username=webdeploy,password=*******
-allowUntrusted=true
This command is also worth explaining in detail:
-verb:sync : makes the web site sync from the source to the destination
-source:package="C:\Build\MyAppName.Debug.zip" : source is an MSBuild zip file package
-dest:auto,wmsvc=webservername : use the settings in the package file to deploy to the server. The user account is an OS-level account with permission. The hostname is specified, but not the IIS web site name (which is previously specified in the MSBuild project file in the project properties).
You can modify parameters based on your configuration. I like it this way because with separate steps, its easier to debug problems.
Use TeamCity build step and the command line runner.
Update:
If you want an example of how to build the ZIP package using MSBuild, try something like this:
"C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe"
MyWebApp/MyWebApp/MyWebApp.csproj
/T:Package
/P:Configuration=Debug;PackageLocation="C:\Build\MyWebApp.Debug.zip"
This should work the same on your local PC as well as on the CI server.
Here are the config settings that finally worked for me:
/p:Configuration=CONFIG-NAME
/p:DeployOnBuild=True
/p:DeployTarget=MSDeployPublish
/p:MsDeployServiceUrl=http://SITE-URL/MsDeployAgentService
/p:username="USERNAME"
/p:password=PASSWORD
/p:AllowUntrustedCertificate=True
/P:CreatePackageOnPublish=True
/p:DeployIisAppPath=SITE-URL
/p:MSDeployPublishMethod=RemoteAgent
/p:IgnoreDeployManagedRuntimeVersion=True
I had exactly the same issue! I've posted the solution I used over at: MsBuild not finding publish profile
Basics were:
Install the Azure SDK 1.8 on the build server
Force the /P:PublishProfileRootFolder value to ensure MSBuild can locate the publish profile
Ensure that you have the Microsoft Web Developer Tools feature installed for Visual Studio. This was missing on my build agent but once I added it the TeamCity build worked just fine.
This can happen when the build target paths are missing from your MSBuild directory. Instead of trying to get those to line up on every developer machine, install the targets from the Nuget. That way it will always be the same for everyone, regardless of how their machine is setup.