Improvement to the Update-Package command

[andrelombaard]

This is not a bug but rather a suggested improvement to the current process when updating all installed packages from the command line using the Update-Package command.

We had a problem a while back where we realized that dll references were not updated to point to the newest version of dll's when using the Update-Package command (To update all our packages). We would for instance update a package from Version 1.0.0 to Version 1.0.1 but the project references would still point to the dll files in the Version 1.0.0 folder. We did some investigations and found that some of the junior developers were not installing the required package for each project, they installed the package for ONE of the projects in the solution and included the references for all the other projects by browsing to the physical location on hard disk. This resulted in ONE project in the solution containing the correct entry for the installed packages in it's packages.config file, when updating the packages by using the Update-Package command, only the references for this one project would be updated.

I suggest that a check is done to verify that all references made to dll's in the packages folder is in fact added to the packages.config file, if a reference is made to a dll in the packages folder and there is no entry in the packages.config file for the package the reference is made from, such an entry should be created in the packages.config file. This will stop the problems currently caused by inexperienced software developers.

[yishaigalatzer]

This could be an interesting Roslyn analyzer. The issue here is that NuGet does not understand the project structure it just removes and adds packages. We can probably prototype a piece of target that you can include in your projects by default, we would probably never make it into a stable product because of the complexity of maintaining it across the variety of versions of visual studio, msbuild and custom build systems.

I'm moving this to client vNext, but we could take a PR for this in our new Entropy Repo, to show the (pretty cool) idea behind it.

[andrelombaard]

Thank you for your reply. I understand that I probably oversimplify the suggested solution here and that it might proof difficult to develop into a stable product. In our setup we experience the problem because we make use of Resharper which will add references for you when hitting the ALT + ENTER + ENTER keys (Direct references). It's easier for developers to ask Resharper to add references for them than it is to install the Nuget package, this however is causing problems, as you can imagine the developer making the direct dll reference (without realizing) get into the 'It's working on my machine but not on yours' situation because he will have all package folders on his local machine.

It will be cool if you can however come up with an elegant solution. Please let me know if you prototype anything or come up with a solution.

[yishaigalatzer]

Ah I see. First of course I would ask the resharper guys to perhaps enhance their feature and add a nuget reference instead of a direct reference. We are building a similar feature in dnx at the moment.

Based on your setup you can build one quite easily, create an msbuild task that runs on build and for example looks at all references that point to the package folder. Then reads packages.config and matches the folder name. I won't get to playing with it any time soon, but it should take a few hours to whip something simple out.

[andrelombaard]

Hi, thank you. I will develop the msbuild task for our setup, should not be to hard as we already have other custom msbuild tasks. Will also log a request with resharper