We would like to start using ProGet for dependencies in CI builds & their dependencies, however this can cause a lot of NuGet packages to sit in the feed and the only option is to delete one at a time or the entire feed.
Is there an alternate way to delete all but the last 10 or better yet implement NuGet package retention policies on the feeds?
Many Thanks
This feature is definitely on our list to implement, though it has taken a back seat to Maven & Linux support for the time being. For now, you can probably whip up a quick PowerShell script though that does something like:
get-childitem "C:\PackagePath\FeedName\PackageName"
| sort-object $.CreatedDate -descending | select-object -skip 10 | remove-item
Of course this uses the modified date instead of the version number, the retention policy feature could use the package's version number to determine which packages to retain.
Update - April 21, 2015:
The retention policy feature will be included in the upcoming ProGet v3.6.
Related
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed last month.
Improve this question
I am trying to install platformio-ide-terminal into Atom 1.63.1. I got the error certificate has expired. I tried alternative Terminus and got the same error. Any package install attempts end with the same error. Please help.
As others have pointed out, GitHub has been ”sunsetting Atom”. Hence its website and all infrastructure have been taken offline. While both major forks, Pulsar and Atom Community, don't provide a full replacement yet, there are other ways to install packages in your existing Atom installation.
Example
# Clone the repository
git clone https://github.com/platformio/platformio-atom-ide-terminal ~/.atom/packages/platformio-ide-terminal
# Change directory to the cloned package
cd ~/.atom/packages/platformio-ide-terminal
# Install dependencies
apm install
If you don't use git, you can simply download the package as zip-file and extract it to the same directory as used in the example above.
Note that some packages might require an additional build step. Take a look at the scripts section of package.json if it includes one or more build commands.
Atom seems dead 🥹 🫶
It seems we have to migrate to "some alternative"…
https://github.blog/2022-06-08-sunsetting-atom/
When we introduced Atom in 2011, we set out to give developers a text editor that was deeply customizable but also easy to use—one that made it possible for more people to build software. While that goal of growing the software creator community remains, we’ve decided to retire Atom in order to further our commitment to bringing fast and reliable software development to the cloud via Microsoft Visual Studio Code and GitHub Codespaces.
On June 8, 2022, we announced that we will sunset Atom and archive all projects under the organization on December 15, 2022.
If I’m using Atom, what changes can I expect after the sunset?
Pre-built Atom binaries can continue to downloaded from the atom repository releases
Atom package management will stop working
No more security updates
Teletype will no longer work
Deprecated redirects that supported downloading Electron symbols and headers will no longer work
This describes a scenario that I find myself in now and then when I realize I should have worked in a development branch in TFS. Then I would like to shelve my changes and unshelv into a dev branch, alternatively create a branch from "Main" with saved, uncommitted changes.
What is described on this linked page and many other pages is possible with earlier versions of VS and TFS using the TF power tools command utility:
http://geekswithblogs.net/TarunArora/archive/2011/06/06/unshelve-shelveset-created-from-one-branch-to-another.aspx
Now those features are no longer available, because "most of the previous Power Tools have been integrated into TFS 2017" (according to https://learn.microsoft.com/en-us/visualstudio/releasenotes/tfs2017-relnotes ). But there is no command line utility AFAIK available to enable such operations.
How can I achieve unshelving to another branch with Visual Studio 2017 and TFS 2017?
Alternatively, how can I create a branch from "Main" with saved, uncommitted changes?
With older versions of Visual Studio (2015 and older), the Power Tools extension (https://marketplace.visualstudio.com/items?itemName=TFSPowerToolsTeam.MicrosoftVisualStudioTeamFoundationServer2015Power) used to unshelve to a different branch. But unfortunately this tool does not exist for VS2017.
I have tried another extension MutliMerge - https://marketplace.visualstudio.com/items?itemName=Jesusfan.MultiMerge2017&ssr=false#overview
I was able to unshelve from a branch to a different branch.
I have ensured that there were no pending changes and both branches were up to date.
Note: the tool did not automatically show me the target branch but I was able to edit it and get to work.
I am trying to upgrade my WFP project from the VS 2015 format to the new VS 17 format. There is a lot of trial and error involved but I have come across an issue which I can find no solution for online:
Some of my code is looking for a file in a certain location:
name C:\git\myproj\packages\A.B.C.Installer.4.1.7\setup\dbpkg\MyProj.dbpkg is invalid.'
Unfortunately the new nuget places the same file in:
C:\git\myproj\packages\a.b.c.installer\4.1.7\setup\dbpkg\MyProj.dbpkg
It does two things different:
everything is lowercase
instead of appending the version, it create a new directory
How can I configure the nuget client to behave like it did before? I am unable to change my code to match.
How can I configure the nuget client to behave like it did before? I am unable to change my code to match.
I am afraid you have to update your code. That because this is the expected behavior now for the new NuGet.
Package ids and versions are case insensitive in NuGet and are now
written out lowercase to the global packages folder to avoid conflicts
on case sensitive file systems.
You can check some more details info from following thread:
NuGet PM 3.5.0 incorrectly using lowercase path in *.nuget.targets
So, if you update your project to the new VS 17 format, you have to update you code to resolve this issue. I saw you saying that you are unable to change my code to match, but this change was designed to make nuget work better, there is no ticket for us to return to the past at this moment.
Hope this helps.
I have set up a VSTS nuget feed. And I have pushed some packages two days ago. I was able to add those packages to my project. But I needed to push an other version for one of them. Made new nupgk version, pushed it and I can see it in VSTS, I can download it from there, Visual Studio 2017 is also listing it correctly but when I try to install it, I am getting an error:
Package 'whatever 1.0.1' is not found in the following primary source(s): 'https://whatever.pkgs.visualstudio.com/_packaging/feedname/nuget/v3/index.json'. Please verify all your online package sources are available (OR) package id, version are specified correctly. 0
What I have tried:
- waiting around 10 minutes
- restarted Visual Studio several times
- pasting the above url into a browser and refreshing it manually several times
One or more of these helped. But I would like to know if there is any canonic solution for that.
I used the answer widget to have some formatting. Still, this might not be "the" answer, as I don't know the mechanism beyond. But it looks to be a workaround.
Steps:
Create a solution with a library project (let's call it L01)
Add another library project to the solution (let's call it D01)
Make a nuget package from L01 (version 0.0.1)
Push the package to your VSTS feed
Manage packages for project D01 and browse your feed
Package L01 v0.0.1 will be listed
Add it to project D01, it will work
Edit L01 nuspec file and change version to 0.0.2
Build and push the new package
Go back to project D01 and refresh the package list. The update will be shown.
Try to update. It will fail with the error message from my question.
Now go to folder %localappdata%\NuGet\v3-cache (or equivalent)
Locate the folder corresponding to your feed and open it
Locate list_l01.lib_index.dat (where l01 is the package name) and delete it
Go back to project D01 and try to install the update. It will succeed.
Would be good if others could confirm. I have reproduced this several times.
Seems you are trying to download the package or packages that where just freshly pushed to VSTS nuget feed.
Since Visual Studio 2017 is listing it correctly, then the issue should not related to the feed on VSTS server.
If this occurs very recently(download the new refresh package) and your package is very large, this maybe a network delay. Suggest you use a fiddler trace when this issue happens again. This makes "some" sense, what you see is probably an incorrect propagation of pushed packages showing up in the search results but not yet available to download.
And some other also encounter the same issue and error as you.
FYI, I've been seeing this exact issue in the past month or so.
Switching between sources, uninstalling and reinstalling are some work
arounds, but not 100%. Pushing my own packages up to VSTS and then
it takes like 15 minutes to finally get it to install.
More details please take a look at this similar issue Package update not found when updating via Visual Studio Solution
I am using Visual Studio Community Edition 2017 and trying to create a UWP application.
I get the following error
Your project is not referencing the "UAP,Version=v10.0.10240" framework. Add a reference to "UAP,Version=v10.0.10240" in the "frameworks" section of your project.json, and then re-run NuGet restore.
I had the same issue on my build machine. What's weird is everything runs fine on my local machine.
I managed to fix this by going into the project properties for my UWP app, and changing the Target version to match the Min version.
The reason I believe this issue is happening is because when targeting a higher framework, on a Windows Server machine (the build agent) it doesn't restore all of the packages between your min and target version. It seems to build fine against the version you target.
By the way Ken, following the instructions given by the error don't fix the issue. Try not to be so rude. I came to this page looking for the same issue, and you are no help at all.
I have the same issue, after I remove my bin and obj folder, I can build mine and see the errors gone.
I recently ran across this same issue when updating the target framework. The issue turned out to be the Nuget Restore task in my VSTS Build definition needed to be updated to the latest version (2.*). Once I did that, the builds worked as expected.
I agree with Jeff. Ken Not sure if you should be giving any answers with this kind of attitude.
The error message is misleading there is not project.json at least you cannot see it in the Visual Studio explorer.
I had the same issue and have min and target version set to the same number but it would not build.
The fix was to make sure in Nuget package manager setting to tick checkbox 'Allow Nuget to download missing packages' and the one below it as well and rebuild the project.
This is a pretty weird mistake, but what worked for me :
1st Solution:
1 - Change your project target to "10.0.10586" (or up)
2 - Make a clean / nuget restore / rebuild
3 - Return the project target to the "10.0.10240"
4 - Make a clean / nuget restore / rebuild
Do not ask me why, but it worked :)
2nd Solution:
If you use a repository with Tortoise, try making a CLEANUP
I had an old Backup folder in my project that contained a project.json. Looks like it might have been from an earlier upgrade. I deleted Backup and got a good build.
This happens in exactly this manner, if projects were generated in the year 2017 in the phase where MS changed to project.json and then decided against it. I tried several solutions (and yeah, Ken White is so wrong!) and the cleanest way was to really build up a new clean project in the lastest and up to date version of Visual Studio (VS2015 did not work sustainable) and just copy over the old project content which is just a few minutes work. This will save you a lot of headaches especially working in a larger team!
I tried the above solutions but nothing worked. I had to backup and remove the UWP project and recreate it from scratch.
I tried a couple of solutions.
Solution 1
Open the solution from Windows explorer and search for project.json files. Open all of them (If you have multiple) and make sure the required framework versions are there. I frequently switch between build 10240 and 17763 and I get this error frequently. (I switch between git branches that target different frameworks of UWP) So instead of adding the exact version I just added only the 10.0 part like this.
"frameworks": {
"uap10.0": {}
},
Now if your project.json files are ok, search for project.lock.json files. If you have one or more of those, delete them.
Now clean your solution
Close VS
Delete all the bin and obj folders.
Reopen the VS and try to run the app.
Solution 2:
Go to project properties
Change the minimum and target version to something else and do a clean build. Then put the actual versions and build again.