The mysterious case of being unable to debug a .Net Core Console application using Visual Studio 2017
This morning I had a very frustrating time. It started off well and I was continuing my drive to convert alot of our hardware services from .Net Framework over to .Net Core. Phase 1 is simply .Net Core running on Windows but then Phase 2 is true cross platform. To date its gone very well and I'll probably write about it further another time.
This morning I was continuing to port code across, mainly making our libraries .Net Standard 2 or .Net Standard 2.0 with .Net 4.5 multi targeting. All worked fine until I converted my final library. The app built, it ran and seemed to be working fine however all of a sudden none of my breakpoints in Visual Studio worked.
During this entire process I have found I've hit many build / compile issues when switching between branches and have often had to nuke my obj folders or do a git clean -xdf but this was not the case. Everything worked bar the breakpoints. The usual tricks didn't work, I even reboot my machine and then checked out the repository again on a different machine just to prove it wasn't specific to my machine.
I would love to say I enabled amazing analytics or debug tools to find the issue but I hadn't. After an hour of pulling my hair out, googling, crossing my fingers, legs and even asking other team members if they had hit this issue I got no where. So it came to divide and conquer. I literally commented out most of the classes in the project I was porting and found it worked perfectly again. So gradually I brought them all back in. I came down to the final 10 classes and then found the class that caused the issue. Initially it looked harmless *DummyDevice* which simulated stuff when testing, I opened it up and again initially it looked OK but I thought, hmm that's doing a Convert.FromBase64String in the constructor, essentially byte array from a known image. I then scrolled right..... and scrolled right.... and scrolled right...
Yup I had a tertiary operator to switch between images that was over 200k of characters long! Turns out .Net Core PDB's don't like this at all! Now the fact this existed in this way is far from ideal, and if I had code reviewed it I would have bounced it but I found I had written it on the 3rd Jan of this year quickly testing out an idea on a prototypes branch that had got merged into the core code base. Bad MJ, never write quick prototype code as you know it will end up in production!
So how did I resolve this issue? For time sake and to not introduce further dependencies I simply took the strings used by the ternary operator and put them into constants. They can then be accessed fine and the debugger is happy again as its not constantly newing these strings up.
An absolutely crazy bug but hey that's what makes developing fun!
:)
This morning I was continuing to port code across, mainly making our libraries .Net Standard 2 or .Net Standard 2.0 with .Net 4.5 multi targeting. All worked fine until I converted my final library. The app built, it ran and seemed to be working fine however all of a sudden none of my breakpoints in Visual Studio worked.
During this entire process I have found I've hit many build / compile issues when switching between branches and have often had to nuke my obj folders or do a git clean -xdf but this was not the case. Everything worked bar the breakpoints. The usual tricks didn't work, I even reboot my machine and then checked out the repository again on a different machine just to prove it wasn't specific to my machine.
I would love to say I enabled amazing analytics or debug tools to find the issue but I hadn't. After an hour of pulling my hair out, googling, crossing my fingers, legs and even asking other team members if they had hit this issue I got no where. So it came to divide and conquer. I literally commented out most of the classes in the project I was porting and found it worked perfectly again. So gradually I brought them all back in. I came down to the final 10 classes and then found the class that caused the issue. Initially it looked harmless *DummyDevice* which simulated stuff when testing, I opened it up and again initially it looked OK but I thought, hmm that's doing a Convert.FromBase64String in the constructor, essentially byte array from a known image. I then scrolled right..... and scrolled right.... and scrolled right...
Yup I had a tertiary operator to switch between images that was over 200k of characters long! Turns out .Net Core PDB's don't like this at all! Now the fact this existed in this way is far from ideal, and if I had code reviewed it I would have bounced it but I found I had written it on the 3rd Jan of this year quickly testing out an idea on a prototypes branch that had got merged into the core code base. Bad MJ, never write quick prototype code as you know it will end up in production!
So how did I resolve this issue? For time sake and to not introduce further dependencies I simply took the strings used by the ternary operator and put them into constants. They can then be accessed fine and the debugger is happy again as its not constantly newing these strings up.
 |
| At least my commit admits mistakes were made... |
An absolutely crazy bug but hey that's what makes developing fun!
:)
Comments
Post a Comment