I have a local nuget repository, where I would like to browse the packages, is there some kind of tool for this?
We have a project that is pushed to my local repository, when we have new updates we just push a new version. We needed to branch the project and therefor we pushed this new version. But I somehow didn't change the package id. So now I need to browse and remove this package, change the id and push it again?
So my questions is, is there any tool I can use to manage my local nuget packages?
I'm not aware of any 'tool' to accomplish this. However, you can manually remove the .nupkg file for the latest (bad) version from your packages folder.
Since you are running the repo from IIS, you can check your web.config file for the following key:
<add key="packagesPath" value="C:\folder\folderHoldingNupkgFiles" />
This will tell you where you .nupkg files are stored. Go there and find the latest version that you published and remove it. Afterward, change the id, etc, and republish as the new package.
Once this happens, you should see the original/previous version from before, as well as you new/branched version.
Related
Github Visual Studio 2022 Git Pull : Will it include the Project's references?
Using Visual Studio 2022 with Git. When pulling from a hosted repository into my local machine, will that also automatically set the same project references in my local machine as it is in the hosted repositories?
What should be the expected behaviour?
Thank you
I tried but I see other references than other users on other machines.
The project references should be defined in the .csproj file (or .vbproj, etc). This file should be included in ones source control repository.
You may need to perform a nuget restore if the references are fetched from a package manager (i.e. https://nuget.org), especially if someone else modified the references and pushed them to your remote in GitHub
For example, someone else on your project updates a reference to a newer version and pushes it up to GitHub. You then perform a git pull on the branch that these changes were made on, and suddenly you have new references or possibly see errors all over your code. When this happens, you almost certainly need to perform a nuget restore to get the new package references.
I happened to get into a bit of a mess yesterday with our NuGet repository, and I've resolved it - but wanted to confirm my suspicions as to why it happened.
I did the following:
Amended some files
Packed the nuspec which includes these files
Pushed to our NuGet repository and confirmed
Confirmed that the NuGet repo had the latest version by downloading them on a dev environment
The changes I'd made were not included in the update in this dev environment (realised I hadn't updated the correct files). So I packed and pushed again without incrementing the version
Downloaded the nupkg on a different dev environment, still the changes were not there.
Took the exact same NuGet package and placed it in a local dir, and noticed when I updated from there it did include the changes.
Question
You'll notice as part of step 4 the old (incorrect) NuGet package was downloaded onto dev environment 1. Would NuGet have known this and, due to a lack of sound versioning, cached or kept hold of this copy somehow (despite my new push) and only allowed other dev environments this version and not the newest?
NOTE: I cleared the local cache on both dev environments prior to any updates made. My question was whether this was a server-side thing or not.
In addition to the copy of the package that is added to the packages folder in your solution NuGet will also cache packages already used in the following directory: C:\Users\YOUR_USER\.nuget\packages. Therefore if you do not change the version after making change you will have to remove the cached version from the directory I listed above for it to get the new changes since you did not change the package version.
I have the similar same problem. It's seem like a old issue.
So I will clear the http cache after I update the package version.
nuget locals http-cache -clear
It will work when you update your project package version.
I have a local NuGet server & NuGet gallery both in version 2.2
I want to update them to 2.8.1, without loosing all my packages and changes I made in the website.
Is there anyway to do so?
Thanks
I would suggest you make a copy of the code/service/web.config files that you have now as a backup. Then open the manage nuget packages dialog, go to update tab, and then click Update All.
If NuGet detect that the package's files have been modified, it will pop up an File Conflict Dialog to ask you if your current files (such as code files) etc. wanted to be overwritten, just answer No to preserver your original files.
Probelm
I want to set-up the no commit workflow for NuGet. But in order to do so, I need to make sure I have copies of any 3rd party packages and there dependencies installed from nuget.org copied to our private repo.
NuGet Mirror
I've looked into the NuGet mirror command, but this looks to be a manual process.
https://docs.nuget.org/docs/reference/command-line-reference#Mirror_Command
NuGet Copy
I also looked into NuGet copy, but could A) not get it to work and B) it still looks like a manual process.
https://www.nuget.org/packages/nuget.copy.extension/1.2.0
Is there any solutions to do this automatically upon package install? I can't force the developers to remember to manually copy the packages after they install them. When the developer installs a package, I want it to be copied over to our private NuGet repo. Please lead me in the right direction.
I'm not aware of any built-in NuGet feature to do this, but here's a simple way to make sure all packages are synced to a shared repository.
NuGet saves all downloaded packages to C:\Users\username\AppData\Local\NuGet\Cache
Just install sync software like BitTorrent Sync on each developer PC and the shared repo server. BTSync will automatically synchronize any new packages to the shared repo as well as all other devs.
I have started creating NuGet packages for some frequent dependency projects we used to use svn:externals for in our ASP.NET solutions. I'm hosting the .nupkg files in a network folder, and using that folder location as a NuGet feed.
I'm unsure what files to place in version control and where. Do you put both the .nuspec AND the .nupkg files in your repository? Do both the .nuspec and .nupkg file go in the project's version control? I thought since the .nuspec file generates the .nupkg file, you'd only need that file in version control. But, I was also thinking it might be a good idea to make the network folder, that I'm using as a NuGet feed, a repo in itself. Then I can version control the .nupkg files.
What are some good practices for version controlling created NuGet packages?
I'm in the same place you are. In keeping with the idea that you don't commit any file that you can build, my .nuspec files go in version control, but the .nupkg files don't.
Since the version number is incorporated into the .nupkg file name, you can have distinct versions of the package in the repository at the same time. You either need to either use the <version>$version$</version> form in the .nuspec file, and set the assembly version to auto-increment, or just manually change the version number each time. You could then make a Subversion tag on that version number, so you could get back to the source for a particular package version if you need to.
In order to let client projects automatically incorporate minor bug fixes in our packages, we're going to enable NuGet Package Restore in the client projects, and publish packages with short, fixed version numbers, like "1.2". When there's a simple bug fix for the package, we'll re-publish with that same version number. That will overwrite the prior version in the repository; client projects will then get the update when they restore packages during the build step.