How to debug your collegues NuGet package

Question

Disclaimer: This is a rather broad topic and there is probably no clear right/wrong. Still I would like to exchange experiences with experts of huge projects to learn and improve work between teams.

Situation

• We have three teams
• Team A and B are developing rather independently
• They both depend on a common library developed and maintained by Team C
• Since we don't want to break everyone's build, if just one Team has issues, we decided that Team C publishes an inhouse NuGet package. Team A and B include that in their projects A and B
• Nobody is perfect, Team C has some bugs and it is hard for them to test parts that the other teams use
• Team A and B can clone the inhouse NuGet package repository and debug code themselves
• Pull requests seem ideal to contribute bug fixes
• Technical setup: TFS 2018, JFrog Artifactory, git, .Net Framework 4.8

So far so good. Here our issues

• Debugging code from project A/B, that is in inhouse NuGet package C, seems cumbersome and tough
• Additionally, Team C would like immediate feedback if breaking the build of another Team
  • NuGet is designed for conscious updates
  • We could not find any way to automatically use the latest version of the NuGet package inside projects A and B
  • Therefore, Team C would get delayed feedback when breaking the build of others
• A lot of manual steps for working with an automatic CI/CD packing system

The question is: How to make debugging as easy as possible in this situation? All we came up so far is to write a Powershell script that swaps all internal NuGet references to real references and imports all respective projects. However, that scripts is probably outdated all the time. Any suggestions how to make our life easy?

• Ron Beyer: stackoverflow.com/questions/24765802/…
• Ron Beyer: BTW, it seems if "Team C" is publishing bug-fixes that break builds, either they are not following SOLID principles, or one of the teams is relying on a specific bug for some functionality. Bug fixes should never break a build. Is Team C doing comprehensive testing? That is, for ever bug submitted they should write a test case that proves it, and then fix the code. All tests should be re-run for pass to verify that no regressions happen...
• tomwaitforitmy: Hey Ron, thank you for your feedback. I saw the exact same link you mentioned. We tried it, but somehow NuGet keeps the same hard coded version as always.
• tomwaitforitmy: To second comment: Bug fixes do not break builds. Changes to public interfaces might. I should have added that the situation is complicated, because all projects are Ui System Tests. Most of it is hardly testable via Unit Tests, because the code works in combination with our products.