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
Related
We currently don't use nuget for our dependencies, preferring to go old-skool way and stick them all in a libs folder and reference from there. I know. So 1990's.
Anyway, nuget has always made me feel a bit queasy... you know, reliance on the cloud and all that. As such, I'm find myself in the main agreeing with Mark Seeman (see here: http://blog.ploeh.dk/2014/01/29/nuget-package-restore-considered-harmful/) who says:
Personally, I always disable the feature and instead check in all packages in my repositories. This never gives me any problems.
Trouble is, this has changed in version 3, you can't store packages alongside the solution, as outlined here: https://oren.codes/2016/02/08/project-json-all-the-things/. Which sorta screws up checking them into source code.
So, am I worrying about nothing here? Should I drink from the nuget well, or side with Mr Seeman and er on the side of caution?
Storing NuGet packages in source control is a really, really bad idea.
I accidentally did it once and I ended up bloating my source code considerably, and that was before .NET Core...
Drink deep from the NuGet well. Most software components are packaged in a similar way these days (NPM, Bower etc). The referenced blog post is two years old and package management is changing rapidly in the .NET world, so here's some of my experience lately.
NuGet packages can't be deleted from nuget.org. They can be hidden,
but if your application requests a hidden package it will download it
as normal. It'll never disappear into the void.
'Enable Package Restore' is no longer glitchy because it's now a default option in NuGet 2.7+. You have no choice anymore.
Packages are no longer stored per solution but per machine, which will save a ton of bandwidth and will decrease the initial fetch period when building.
If you build a new project using .NET Core, you will have dozens more packages as the entire BCL will be available as NuGet packages. Do you really want to check-in all the System.* packages into source code?
There is a very simple reason why you want to store Nuget packages in source control. Your organization doesn't want your build server to have internet access.
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.
I found Autofac AggregateService awesome but what is the right way to include it in my project: clone it from code.google.com or use NuGet?
I got used to use NuGet but I can't find nothing about AggegateService there. Any help?
It seems that AggregateService and the other Extras are currently "in limbo". There's been a recent change in that the contributions are now being made part of the same solution as Autofac core, while they were previously a separate solution. From the current build file you can see that extras will be made available as a separate Autofac.Extras package and a separate download from the Autofac page.
Meanwhile, you can use AutofacContrib 2.6.1 or to grab the source and compile a dll yourself.
Btw, thanks for finding AggregateService awesome ;)
Update: actually, reading the build file properly (and looking at the current source structure), the Extras parts will be distributed as individual packages. So expect to find Autofac.Extras.AggregateService on Nuget in the future.
When creating a nuget package, the version in the file name of the nuget package seems to come from the AssemblyInfo file in the web application project. I have also created a version attribute inside the nuspec file.
What is the relationship between these two version numbers and are there any conventions attached?
With regards to convention, the NuGet software itself, and the semantics it applies to packages in the gallery, does versioning as described by SemVer.
Specifically you can designate beta versions by suffixing your nuspec version number with "-beta.4" or something. For example, see how the gallery displays the latest version of AutoFac, and compare how it displays an old release (note the text "This is not the latest version of Autofac available." Edit: The gallery no longer seems to provide any special message for non-current versions) and an old PRE-release version (with the text "This is a prerelease version of Autofac.").
Unfortunately, the AssemblyVersion in AssemblyInfo.cs may not contain letters or hyphens, so it can't be used in this way. However the AssemblyInformationalVersion MAY have letters and hyphens in it and, if you provide it, NuGet will use that instead of the AssemblyVersion to replace the $version$ token in your nuspec file. What's more, the AssemblyInformationalVersion (also called the "Product Version" if you check a DLL's details in windows explorer), at least to me, better represents what the NuGet version should match.
I have a slight concern with this approach in that I'm expected to leave the AssemblyVersion the same through various beta iterations and a final production iteration of the AssemblyInformationalVersion, which means I'm allowing several different versions of my DLL into the wild that may behave differently or incorrectly, yet are all identical as far as the CLR is concerned (the CLR only cares about AssemblyVersion). In practice, though, this happens frequently (including with the AutoFac packages described above) and it doesn't seem to cause a problem.
See the two excellent highest-voted answers to What are differences between AssemblyVersion, AssemblyFileVersion and AssemblyInformationalVersion? for more info on AssemblyInformationalVersion and friends.
There doesn't need to be a relationship between the assembly version and the nuget package version. By convention, many maintainers use the same number for both.
The convention for using the same number is also the nuget.exe default if you have no nuspec, or you use nuget.exe spec to create a tokenized nuspec file. However, if you replace the $version$ token with a value, then that value will take precendence and will be used in the package file name.
You can also set the version on the command line, which takes precedence over all of the above.
More info on Xavier's blog: NuGet $version$ token explained
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