I am wondering whether it is possible to update package that was installed with /x flag?
For me it seems that it is not possible right now. What I mean by updating is making packages.config change with greater version of given package (done by nuget.exe update SolutionName.sln)
What is the flow of update operation? Does it look inside nupgk of actually installed package? Or it just search for version within directory name?
When version in directory name is missing is there a problem with version comparison?
I need precise explanation.
Note:
I use nuget 2.8.50224.430
I created identical thread on nuget codeplex here:
https://nuget.codeplex.com/discussions/543299
I think I managed to answer my own question.
While waiting for response I decided to look at nuget.exe sources and find how is version from installed package gathered.
What I realized:
1. Version is taken directly from packages.config.
2. nuget update command looks for PackageName.PackageVersion.nupkg in packages directory.
3. When wanted file does not exists, update cannot be completed (it is aborted).
I tried to change code to use directory and package name without version.
It is possible but it will be better to request another flag for that purpose.
For curious: PathResolver is created in UpdateCommand.cs
var pathResolver = new DefaultPackagePathResolver(sharedRepositoryFileSystem);
You can pass false as second argument to omit version in path concatenation.
Related
We have many libraries which are build in a CI, which deploy prereleases every time they build. Other projects depend on these and automatically updates them during build.
But the references are set with the Specific Version = true, which means that increasing the version number on these dlls causes the build to fail.
How can I control the setting of the property?
You cannot change NuGet's behaviour without changing its source code. NuGet will always sets SpecificVersion to true when adding a non-GAC assembly from within Visual Studio.
You would need to run some sort of post build script to fix the references or manually change them.
Not sure exactly how you are updating the projects in your CI server. If you use NuGet.exe update project.csproj then that will update to the latest NuGet package and will not set SpecificVersion to true. However the command line application does not support PowerShell scripts or content files, only references will be updated. This also assumes that there is an update available otherwise the reference will not be modified.
I've created a folder on my C:\packages. Inside I've created two packages with identical Ids but have different versions. I the use Nuget.Core to create a LocalPackageRepository pointing to this directory.
When I query for the packages using respository.FindPackages("myId")both packages are correctly returned by the service. However, the IsLatestVersion is true for both packages, even though their versions are clearly different.
Things I've tried:
I know these packages dicovered as OptimizedZipPackages looking through the source here, I cant find anything relevant to suggest an issue with the implementation.
I added the local repository to my Visual Studio NuGet feed manager. When I query that service, the latest version is shown.
Something seems to be wrong with how I've either created the packages, instantiated the repository, or its a bug in the library.
Using NuGet Core v2.8.60318.667
Looking at the source code the LocalPackage always returns true for IsLatestVersion if the NuGet package is not a pre-release.
In Visual Studio what happens is that the list of packages is further filtered by removing all but the latest version in the list so you only ever see the latest version. One way to do this is to use extension methods included in NuGet:
packages.DistinctLast<IPackage>(PackageEqualityComparer.Id);
The DistinctLast method assumes that the same NuGet package id will appear together in the list otherwise it will not filter them correctly.
I believe you could also use the AsCollapsed extension method which is similar to the above. It basically does:
packages.DistinctLast<IPackage>(PackageEqualityComparer.Id, PackageEqualityComparer.Version);
I just published a package to nuget but realize I forgot to include a css file. My versioning is tied to the library I'm packaging (which I don't own) so I can't really increment it.
How do I force a re-push or what's the recommended thing to do in this scenario?
Found out an answer to my own question.
There is apparently no limit on how many version places there are so you can simple append yet another version place.
So for example if the package you're packaging is 0.0.1 you can upload another one 0.0.1.1
My aim is to have package restore working on a build server so that I don't have to check in binaries. At the moment, I'm simply trying to get it to work on my own machine using Visual Studio.
Here's what I've done so far:
Followed the instructions here http://docs.nuget.org/docs/workflows/using-nuget-without-committing-packages, including both setting the Tools-Options flag and the environment variable (belt and braces)
Installed the NuGetEnablePackageRestore package as suggested here NuGet package restore consent without NuGet
Checked everything in (the .nuget solution folder and its contents), but not the binaries I want to reference, because that's the whole point of the exercise
Here's what I'm doing:
Check out solution
Verify that nunit.framework.dll and moq.dll are not present in the checked out solution
Build the solution
Visual Studio complains that Moq is missing. I search for the dlls in the solution directory and find that:
nunit.framework.dll is present in the appropriate bin folders
Moq.dll is nowhere to be found
But there's more. This is truly mysterious, but if I do a fresh checkout, disconnect from the internet and build, I get precisely the same results - nunit.framework.dll is there, but moq.dll is not. The build process has conjured nunit.framework.dll literally from nowhere.
So it's something of an understatement to say that I am completely baffled. Can anyone suggest answers to the following questions:
Why is package restore not downloading Moq?
Where on earth is the build process getting nunit.framework.dll, if not the internet?
In vs, Options, Package Manager... there's a section "Package Cache", if you click on the "Browse" button it will take you to the location of the nuget cache in your machine.
Okay, I noticed in the documentation that enabling package restore was supposed to modify project files in order to add a new target. My project files did not have this change. Right-clicking the solution title in VS and selecting 'Manage NuGet packages...' then added the required changes and everything built as it should.
I checked, and package restore still appears to work when I have no internet access, so I'm still mystified about that. Does NuGet maintain some kind of cache of binaries outside the solution?
I've done a fair bit of reading on NuGet, and I can't seem to find what I want. Essentially, I'm hoping that it will work like Apache Ivy, where you can just check in your config file (without any binaries) and tell NuGet to fetch all the DLLs -- thus saving you from versioning tons of DLLs.
Hence: is there a command in NuGet to fetch and configure all dependencies mentioned in packages.config?
Again, the case for this is that I only checked packages.config into source control, not the actual DLLs, and I need to re-fetch everything. (Preferably without fetching packages one by one by name).
This has been covered recently in blog posts:
Inbuilt functionality for this is coming in a future version of NuGet: http://feeds.haacked.com/~r/haacked/~3/x8g_kFzD4eA/feedback-request-for-using-nuget-without-committing-packages.aspx
(Linked from above) How to do this today using command line NuGet.exe (available from the NuGet pages on CodePlex): http://blog.davidebbo.com/2011/03/using-nuget-without-committing-packages.html
EDIT: Now also covered on NuGet's Documentation Pages