Removing the version parameter from the packages.config file does not work

Topics: General
Apr 14, 2013 at 7:07 AM
Hi,

When installing a package or bunch of packages into a project, a packages.config file is being created and a new line for each package is being created in it. One of the parameters in this line is the "version" parameter.
Now let's say there's a certain initial version number for this parameter and whenever a newer package is being installed, the value of this parameter will be changed to the new version number. If one developer has updated this package two days ago, and another developer is updating this package today to a newer version than the other developer, commiting will cause a conflict. It is a never ending story.
Not commiting the packages.config will cause NuGet to fail when the initial version of the package will not exist anymore in the NuGet server (Is it a bug? Works as designed?)
Whan we have tried to do is to commit only one version of packages.config when the version parameter's value is empty but it does not work.

Am I missing something? What is the preferred way to work with the packages.config files?

Thanks
Gil
Apr 14, 2013 at 7:14 AM
kingikra wrote:
Now let's say there's a certain initial version number for this parameter and whenever a newer package is being installed, the value of this parameter will be changed to the new version number. If one developer has updated this package two days ago, and another developer is updating this package today to a newer version than the other developer, commiting will cause a conflict. It is a never ending story.
How is it different than any file belonging to source control? The second developer will just need to solve conflict and pick his version before checking in.

The preferred way to work with packages.config files is NOT to touch it at all. Let NuGet manage it on its own.
Apr 14, 2013 at 7:24 AM
dotnetjunky wrote:
kingikra wrote:
Now let's say there's a certain initial version number for this parameter and whenever a newer package is being installed, the value of this parameter will be changed to the new version number. If one developer has updated this package two days ago, and another developer is updating this package today to a newer version than the other developer, commiting will cause a conflict. It is a never ending story.
How is it different than any file belonging to source control? The second developer will just need to solve conflict and pick his version before checking in.

The preferred way to work with packages.config files is NOT to touch it at all. Let NuGet manage it on its own.
First of all thanks for the fast response.
What I did not understand is your last sentence. If I won't touch it at all, at one point, the version of a package will be so old that it'll not be present in the NuGet server.
(We cannot leave all packages in the NuGet server as it'll grow in size to be a monster).

Thanks
Gil
Apr 14, 2013 at 3:34 PM
If you want to update your packages to the latest version, switch to the Updates tab in the Manage NuGet packages dialog, or use the Update-Package command in the console, to update the packages. Both ways will update the packages.config file for you.
Apr 15, 2013 at 11:57 AM
dotnetjunky wrote:
If you want to update your packages to the latest version, switch to the Updates tab in the Manage NuGet packages dialog, or use the Update-Package command in the console, to update the packages. Both ways will update the packages.config file for you.
You got me wrong.
I'm not looking how to update packages. What I'm looking for is a way work with the packages.config files so at one point my build won't fail.
Let me write scenario:
a developer is working on a solution with one project. he is updating one of the packages. Other packages stays with an older version. he is working for a month or two. Meanwhile, the artifact server is getting full so we'll need to delete the old packages. We delete all packages from 1.0.0.0 to 1.0.100.0.
The developer's packages.config file contains a line of a package with version number: 1.0.88.0. If he'll clean the local packages folder and try to compile, compilation will fail because NuGet will not be able to find 1.0.88.0 anywhere.

Hope that was clearer.

Thanks
Gil
Apr 15, 2013 at 3:35 PM
Ah I see. Sorry for misunderstanding your case. I'm not sure if package restore is designed to solve that problem. For package restore to work, you must have the exact version of the package available on the server.