title: How should I use Nuget for internal enterprise development?
body: <p>We use Nuget for our internal development to allow us to share code across teams. We run into issues however when one person is working on code that will be deployed across multiple nuget packages at the same time. For instance</p>
  
  <p>A depends on B which depends on C. </p>
  
  <p>A, B and C have their artifacts pushed to Nuget and that's how we manage the dependencies between A, B and C. The trouble we find is that if a developer wants to make changes in C and quickly see those changes reflected in A, they have to go through the following process.</p>
  
  <ol>
  <li>Make change in C.</li>
  <li>Push change up to git</li>
  <li>CI picks up change to C and builds and deploys new nuget package.</li>
  <li>Go into B and update reference to C using a nuget update package command.</li>
  <li>Push up the change to the packages.config file up to git</li>
  <li>CI picks up change to B and builds and deploys new nuget package for B</li>
  <li>Now open A and change reference to B and nuget update package</li>
  <li>Make changes in A to go along with the changes in B(and transitively C)</li>
  </ol>
  
  <p>This seems extremely painful and is causing some of our developers to question the choice of Nuget for our internally developed code. Everyone still like it for consuming external packages.</p>
  
  <p>Is there any better workflow for using Nuget internally? </p>