I have uploaded a package(com.test:project0.1) in azure devops Artifact, however when I am making changes in code, the pipeline is getting successful but unable to replace the old package.
Can anyone please assist me.
If you used another nuget package to replace the old one, also, you have set the same version as the old before, then you should remove the old nuget caches first to remove the old one.
You should check the option Disable Local Cache option.
Then, re-run to check that.
Also, if you push a version number for the nuget package, you should modify the nugrt version under csproj file to the new one.
Related
I want to publish a new version of a NuGet package, but I want it automatically in an Unlisted status. When I manually upload the .nupkg file to nuget.org, in the preview there is an option to unlist the package from search results:
Is there a way to do that with nuget.exe or dotnet nuget?
I was able to use PUSH + DELETE commands to achieve this, but I'm not sure this is the same as the above manual action.
For instance, one of the concerns is what happens to the package's RSS (atom.xml)?
Does it first get a new entry which is then deleted later on? In which case, is it possible that someone would still get notified about this release?
Last, I am aware of private NuGet feeds, but regardless, I would still like to use just the main NuGet, for convenience's sake.
I have a single .NET solution with multiple class library projects, each one is published as a nuget feed using azure-devops.
Then I have an azure-devops build pipeline, with steps to Restore, Build, Publish, Pack and Push.
The first 4 steps are setup for **/.csproj and the last is a $(Build.ArtifactStagingDirectory)/.nupkg with the target feed.
I have everything set up and working, except if you make a change to just one project, it builds ALL projects because of the **/*.csproj.
This is no good for nuget packages, as it increments every project's version number and they all appear as having an update available in the nuget package manager.
My Question: Is there a way to do this so that only the project(s) with changes go through the process?
Is there a way to do this so that only the project(s) with changes go through the process?
The answer is yes.
The solution is use the private agent to build your solution instead of the hosted agent.
That because every time the hosted agent assigned to us is a clean machine, VS/MSbuild will build all the projects for the setting **/* csproj. So, to resolve this issue, we must save the results of the last build to achieve incremental builds.
So, to resolve this issue, we need to set up a private agent to build those projects and do not clean the working directory of your private agent before the build is run:
Set the Clean option to false on the Get sources:
Note: Since you also set the **/*.csproj for the task nuget push, if the project not modified, this command will push the same version to the feed, it will throw the conflict error, you need enable Allow duplicates to be skipped on the nuget push task:
Hope this helps.
I'm at wits end here. I've tried everything I can find to get NuGet to restore my packages on the TFS build server and nothing seems to work. (The latest changes I checked in I got here). I have read a lot about problems with older versions of the Build Process Template, so I just changed the build to use TfvcTemplate.12.xaml and still no packages are restored. This latest change (from the link above) had me delete the NuGet.targets file and now I get an error saying:
This project references NuGet package(s) that are missing on this computer.
Enable NuGet Package Restore to download them. For more information, see
http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is
:\Builds\TFS\WebApps\src\WebApps\Main\Src\\.nuget\NuGet.targets.
Since you have tried so many solutions based on google. Which may make your environment complex and confusing.
First there are two ways to do the nuget restore MSBuild-integrated restore and Automatic restore in Visual Studio. There are totally different things.
With NuGet 2.7 and later, Visual Studio automatically restores missing
packages by default at the beginning of a build.
Since you are using NuGet 3.4, suggest you to use Automatic restore.
You could only select one way to do the restore operation. Based your error message NuGet.targets not found, maybe you haven't finished Migrating to automatic restore step. Please do it again or double check this.
You could also test the migration, do the following:
Remove the packages folder from the solution.
Open the solution in Visual Studio and start a build.
Automatic restore should download and install each dependency
package, without adding them to source control.
Do not add $(SolutionDir).nuget\nuget.exe restore -SolutionDirectory ..\ to the pre-build event on my first project in the build order . This is the old way to do the restore. Just like the way describe here.
Nuget Restore.exe was added to the 2013 (v12) templates. Since you are using the TfvcTemplate.12.xaml , you don't have to add it again.
Highly doubt you were mixing up the two ways cause your present dilemma. Suggest you follow the automatic restore process, use a clean environment, complete migration to automatic restore step , test the migration locally, make sure NuGet.exe and NuGet.targets files from .nuget folder in source control are removed, checking pending changes, check your TfvcTemplate.12.xaml Process Templates with Nuget Restore functionality. Create a new build definition with old settings and use the template. Finally trigger the build...
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.
I have two VS 2013 projects in separate solutions, one of which uses NuGet to manage/consume the other.
I need to change the second project and want to test it in the first one, but I can't publish to our local NuGet repository, in case someone accidentally uses it. Now that I think of it, I don't have publish rights anyway.
I'd like to temporarily, locally redirect the reference to this second, modified project in the first one. How best can I do that, ideally with as little disruption and cleanup when testing is done?
Add a local directory as a NuGet source.
Create a package of the project you want to test and copy it to this directory in step 1
Install the new package from NuGet Package Manager and test.
This way you dont have to change project refs etc.