You can even create your own internal NuGet server if you want but that is outside of the scope of this article. The word local here does not have to be taken literally – a network share or even a file share on Azure (AWS / etc.) will work. The first step required is to create a local NuGet folder to host the debug NuGet packages. Setting Visual Studio to use a local feed for NuGet packages Creating the local NuGet feed folder When the class is inside a NuGet package and we “F11” at our breakpoint on var contact = new Contact ") ), we are basically back to where we started:īelow are the steps on resolving this issue.
Visual studio 2018 default namespace code#
For this simple scenario, a few clicks of “F11” to step-into the code would locate our issue.īut wait, the class is in a NuGet package, not our solution... As you can see, it will create a new Contact and then write the details to the screen.įor this example, we’d probably set a breakpoint on line 9 (as with everything in Visual Studio, there are many ways to do this - selecting the line and clicking “F9”, clicking in the left most column etc.) but we’d end up with a breakpoint:ĭebugging from here is as simple as clicking “F5” (if you prefer the menu option: Debug > Start Debugging). The screen-shots are from Visual Studio 2017 Enterprise, but NuGet Manager has been available in Visual Studio since Visual Studio 2010 and is available in all editions including Community.īelow is a very simple Main method. Net Framework 4.6.1 but, that was for simplicity and I mention for reference only - any supported language will work VB. The screen-shots that follow have been taken from a scaffolded Console Application with no meaningful changes - I used the. Often this won’t be an issue as the defect you are hunting down will be elsewhere, but what about when it’s not? What about when the code containing the bug is in a NuGet package you’ve created? Debugging in Visual Studio - A Quick Overview This post isn’t intended to give a deep, exhaustive explanation of debugging - there is a brief overview in a moment - the intent here is to help solve the frustrating moment when you try to debug into a method only to find Visual Studio steps over the code (as it is in an included NuGet package rather than when you accidentally hit F10 instead of F11 - we’ve all done it!) and continues on its merry way. OK, maybe it is not really an obvious problem, but given the title of this blog, I hope it comes as no surprise! After all, we’d only have 3-5 packages, right? Wrong! Whilst we genuinely thought there would not be hundreds of packages (and we were right on that!), we have reached 21 packages and, along the way, encountered the obvious problem debugging. The customer had an on-premise TFS Server which we already used for the build process so the solution was simple: NuGet the methods and use TFS to host the feeds. We had many hundreds of useful methods with thousands of lines of code and, whilst we could simply copy-n-paste the methods, that was clearly not a practical or sustainable solution - not to mention its total disregard for Don’t Repeat Yourself. This decision was primarily based on start-up time of the application when debugging locally but presented an old foe - duplication of code. However, early in the project, we took the design decision to break the new APIs into their own solutions. Over the past year, I have been working on a programme of work that, initially, was intended to extend an existing Azure Service Fabric solution by adding a further 14 WebAPI endpoints.