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.
Related
Scenario: We wanted to move some code over to a new repo (NewSln), so we created that new repo, and then added the code back as a submodule in the original repo (OldSln). Had to modify a few references to point to the new version, but was able to get the build to work locally.
Issue: After doing this, the Azure Devops build failed on the msbuild building step due to
Error : This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them. For more information, see http://go.microsoft.com/fwlink/?LinkID=322105
The missing file is ..\..\..\packages\Fody.6.5.2\build\Fody.targets. and other similar issues. We had not made any changes to those references
I noticed that the restore step was restoring the packages to the submodule directory. For example, I saw this line
2022-02-10T23:52:45.1474898Z Adding package 'AcisExtensionSDK.1.0.4.1061' to folder 'C:__w\1\s\NewSln\packages'
I confirmed that this submodule is only used by the larger repo and not the submodule, yet it is being restored to \NewSln\packages\ rather than \packages\
Debugging effort so far: I can see the references that are showing up as missing on the build locally, and the build is working locally, with nothing obvious to me as why it fails on dev ops. I also see various stack overflow posts about the opposite issue, where the nuget restore doesn't import the references for the submodule repo, but I found nothing for the case where only the submodule repo is restored.
Is there anything that could cause this and what would be the way to route the packages being restored back to the appropriate package?
Quite often when installing some of the js* library packages nuget copies js files to Scripts directory of the web project and puts these files under source control.
Yet while updating the package instead of just rewriting the files nuget first removes them and then copies new versions. Because of that TFS shows the error about conflicting state: Files are scheduled for removal but present locally.
Can we somehow change this behavior or is it completely defined by the author of the package?
No, this behavior is not defined by the package author.
And since NuGet 2.5, it is allowed to overwrite content files that already exist. Check: https://docs.nuget.org/release-notes/nuget-2.5
You need to use the Update-Package command to update NuGet packages.
What are the benefits for enabling the Nuget Package Restore feature in my Visual Studio solution?
The "Using NuGet without committing packages to source control" page in the Nuget Docs site suggests one reason:
When using a DVCS like Mercurial or Git, committing binaries can grow
the repository size like crazy over time, making cloning more and more
painful
Do you find this reason compelling enough to enable the feature? Are there other reasons?
There are more benefits of not having your NuGet package binaries in source control which are explained on another page, which I have reproduced here:
Distributed version control systems (DCVS) include every version of every file within the repository, and binary files that are updated frequently can lead to significant repository bloat and more time required to clone the repository.
With the packages included in the repository, team members may add references directly to package contents on disk rather than referencing packages through NuGet.
It becomes harder to "clean" your solution of any unused package folders, as you need to ensure you don't delete any package folders still in use.
These benefits are still related to not having the NuGet packages in version control. So the reason you highlighted is still valid.
Also note that the "Enable package restore feature" which uses MSBuild based package restore has been deprecated by the NuGet Team in later versions of NuGet because it has problems with NuGet packages that include custom MSBuild targets. Instead the NuGet team recommend to not use it but instead use the Visual Studio based package restore which will restore NuGet packages just before you build the project inside Visual Studio.
Also when NuGet was first released the NuGet team at the time expected you to put the binaries in source control so you did not have to rely on NuGet when you wanted to build your project. So a developer could clone the repository and build the project straight away without having to use NuGet. However you now have a choice.
When you are working with a large version control repository, such as MonoDevelop, then including binaries can make the repository very large. For smaller repositories including the NuGet packages is not really a problem.
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.
So I would like to use NuGet to manage the various projects I use for a specific project my team and I are working on. Up to this point, I have placed my .js library files in the /Scripts directory of my web solution (ASP.NET MVC 2) and referenced those. Of course, this was manual and was annoying to manage during upgrades, etc.
Now that I am using NuGet, I realize that the entire goal of NuGet is to make this fairly painless. In addition, it appears that I shouldn't have to check my packages into my repository (AKA I don't need to manage my external libraries anymore). However, when I grab jQuery (for example) from NuGet, it places its specific files in the /Scripts directory of my project.
Where I get confused - what, if anything, should I check into source control at this point? Do I still check in the /Scripts directory?
In addition, if someone else is working on this project and checks out the solution from source control, are the packages automatically downloaded (assuming the solution comes with a valid packages.config)?
I'm just trying to clarify a couple points before we start using NuGet full-time.
There are two scenarios for NuGet vs VCS: to check-in or not to check-in, that's the question.
Both are valid in my opinion, but when using TFS as VCS, I'd definitely go for a no-checkin policy for NuGet packages.
That being said, even when using a no-checkin policy for NuGet packages, I'd still checkin the content changes that those NuGet packages have done to my projects. The \Scripts folder would be checked-in in its entirety (not selective, not ignored).
The no-checkin policy for packages to me means: not checking in the \Packages folder (cloak it, ignore it), except for the \Packages\repositories.config file.
As such, you are effectively not committing any NuGet packages, and when using Enable-PackageRestore from the NuGetPowerTools (this will be built-in in NuGet v1.6 just around the corner), any machine that checks out the code and builds, will fetch all required NuGet dependencies in a pre-build step.
This is true for both local development machines as for build servers, as long as Enable-PackageRestore is enabled in your solution and points to the correct NuGet repositories (local, internal, external).
If you think about it, when installing a NuGet package that only adds references to some binaries, you'd already be doing the samething in a no-checkin scenario: you would not commit the \Packages folder's subfolders, but still, you'd commit the project changes (the added reference).
I'd say, be consistent (for any type of package), whether it contains binaries only, content only, or a mix. Do not commit the packages themselves, do commit the changes to your sources. (if only to avoid the hassle of looking up what changed content-wise)
NuGet, like Nexus, are artifact repository (artifact being any type of deliverable, including potentially large binary).
The side-effect is for you to not store in an VCS (Version Control System) elements that:
wouldn't benefit from VCS features (branching, merging)
would increase significantly the size of the VCS repository (no delta or weak delta storage)
would be quite hard to remove from a VCS repository (designed primarily to keep the history)
But the goal is for you to declare what you need (and let NuGet fetch it for you) instead of storing it yourself.
So you can version /Scripts as a placeholder, but you don't need anymore to versioned any of its content now fetched automatically.