When installing or updating a NuGet package, the package is placed in a folder that contains the version number of the package being installed.
This breaks version control, since the old package is not removed from version control and the new package is not added to it. In Subversion for example, this then requires a not insignificant amount of cleanup.
This problem also affects continuous integration build servers, where the build script usually needs to be edited to take account of the new path (I've run into this problem specifically with Machine.Specifications, which has a test runner that needs to be launched on the build server).
It would be really, really, REALLY useful if one could install a package into a folder that doesn't contain any version number, so that the folder name never,changes. This could be specified per-package in the user interface when the package is first installed, and/or as a default in the NuGet settings.
Comments: As the original reporter of this issue, I think it is worth revisiting this as my original report is quite old now and the world has moved on a bit. I can see way NuGet does things the way it does and I realised it is going to be difficult for them to resolve this issue, There is a tension here between simplicity for small projects and flexibility for large/complex projects. I suspect this is one of those situations where it is impossible to please everyone, therefore I have looked for alternative solutions. The source control aspect of the issue has probably gone away (at least for me). I think when I posted the original issue I had a particular way of working based on a philosophy that came from Subversion; we liked to have library binaries committed in version control along with source. We were using version control to solve a build problem, essentially. Nowadays we use Git and TeamCity and our trust in NuGet has grown to the point where we don't really care about having libraries committed to version control, we just pull them from NuGet on demand. We also have our own internal NuGet server (provided by TeamCity) and we use that to manage dependencies at the package level, instead of trying to include other sources ('SVN Externals'). The second part of the problem, version numbers breaking references to executables in the Tools directory, has also largely gone away. This one has been solved for us by TeamCity, which evolved to embraced NuGet and lets us control how we restore NuGet packages, including an option to drop the version number. We now do a NuGet package restore as a separate build step using the TeamCity NuGet runner, before compiling anything, so we get a full package restore with versionless folders. This means our tools location never changes. I've never been in a situation where I wanted to do this, but I think we can still have different projects referencing different package versions, by enabling restore-on-build, with version numbers enabled. This would result in two NuGet package restores, once as a pre-build step done by TeamCity and then again as part of the MSBuild process, which may seem wasteful but it achieves the desired result. On that basis, for me personally, this entire issue has gone away and is no longer an issue. I have found solutions to both aspects of the problem by other means. Rather than trying to force NuGet into my old-world thinking, I have taken advantage of evolving tools and adjusted my build strategy.
This breaks version control, since the old package is not removed from version control and the new package is not added to it. In Subversion for example, this then requires a not insignificant amount of cleanup.
This problem also affects continuous integration build servers, where the build script usually needs to be edited to take account of the new path (I've run into this problem specifically with Machine.Specifications, which has a test runner that needs to be launched on the build server).
It would be really, really, REALLY useful if one could install a package into a folder that doesn't contain any version number, so that the folder name never,changes. This could be specified per-package in the user interface when the package is first installed, and/or as a default in the NuGet settings.
Comments: As the original reporter of this issue, I think it is worth revisiting this as my original report is quite old now and the world has moved on a bit. I can see way NuGet does things the way it does and I realised it is going to be difficult for them to resolve this issue, There is a tension here between simplicity for small projects and flexibility for large/complex projects. I suspect this is one of those situations where it is impossible to please everyone, therefore I have looked for alternative solutions. The source control aspect of the issue has probably gone away (at least for me). I think when I posted the original issue I had a particular way of working based on a philosophy that came from Subversion; we liked to have library binaries committed in version control along with source. We were using version control to solve a build problem, essentially. Nowadays we use Git and TeamCity and our trust in NuGet has grown to the point where we don't really care about having libraries committed to version control, we just pull them from NuGet on demand. We also have our own internal NuGet server (provided by TeamCity) and we use that to manage dependencies at the package level, instead of trying to include other sources ('SVN Externals'). The second part of the problem, version numbers breaking references to executables in the Tools directory, has also largely gone away. This one has been solved for us by TeamCity, which evolved to embraced NuGet and lets us control how we restore NuGet packages, including an option to drop the version number. We now do a NuGet package restore as a separate build step using the TeamCity NuGet runner, before compiling anything, so we get a full package restore with versionless folders. This means our tools location never changes. I've never been in a situation where I wanted to do this, but I think we can still have different projects referencing different package versions, by enabling restore-on-build, with version numbers enabled. This would result in two NuGet package restores, once as a pre-build step done by TeamCity and then again as part of the MSBuild process, which may seem wasteful but it achieves the desired result. On that basis, for me personally, this entire issue has gone away and is no longer an issue. I have found solutions to both aspects of the problem by other means. Rather than trying to force NuGet into my old-world thinking, I have taken advantage of evolving tools and adjusted my build strategy.