Developing and Debugging with Nuget libraries

Question

We have chosen to use nuget for managing private (.NET) libraries but already versioning of DLLs is getting tiresome.

Let's say we have the following Shared Libraries across two project:

• Shared_DAL
• Shared_Model
• Shared_BLL (Depends on Shared_DAL and Shared_Model)
• Shared_Mvc (Depends on Shared_BLL and Shared_Model

Then, in each specific project we have:

• Project_Model (Depends on Shared_Model)
• Project_BLL (Depends on Shared_DAL, Shared_Model, and Project_Model)
• Project_Mvc (Depends on Shared_Model, Shared_BLL, Project_Model, and Project_BLL)

The problem we have right now is that it is very difficult to test changes made to Shared_BLL in a specific project. Currently, we have to:

• Build Shared_BLL as a nuget package
• Deploy the nuget package to the private repository
• Run Update-Package Shared_BLL in the solution containing Project_Mvc and Project_BLL

This is extremely difficult and a big overhead.

We tried another approach where one would temporarily remove the DLL references and substitute them with direct references to the modified DLLs. But then, you have to undo all your changes to the project which is not particularly great.

Am I missing something here? If you're using NuGet in your development life cycle, how are you dealing with DLLs?

Update: For people who are facing the same problem, we've moved away from nuget until this gets sorted out, and rely on putting DLLs in a specific folder, and use absolute paths in the HintPath in each project file. Build events update the DLLs in the defined directory and both Shared and Project can be debugged.

Answer 1

I see you returned to referencing to plain DLL instead of nuget package, but I decided to answer. Maybe someone else will be interested in my opinion on this topic.

Lastly I did huge research on that and I found some facts that can be used to work around issues with switching between remote nuget reference and local nuget reference.

It is possible to call nuget update to reference newest version of requested package. So... for example you have two nuget repositories (remote and local). Local repository is normal folder.

1. You build Project_Mvc from plain sources and nuget automatic restore downloads
   Shared_BLL-1.0.0 from remote repository where you have your "production builds"
2. You decided to build Shared_BLL locally. As you do it in your IDE it generates
   Shared_BLL.9.99.999.0 package.
3. You call update and rebuild Project_Mvc and voila! Shared_BLL.9.99.999.0 is now
   referenced here.

You wrote that this is big overhead... It can be done automatically by adding additional projects to VS solution. For example _UpdatePackages project (Empty C# project template) which will be always on top of solution's project list. Additionally, this can be done backwards also. When you delete Shared_BLL.9.99.999.0 from local feed and call update - reference will be replaced with that from point 1.

Another way to handle this problem is using ripple. I could not use this in my project because of some constraints but it may be ok in your situation.