Debugging Setting Help

I set something bad, and I can't find what or where it is, so I'm hoping somebody can point me in the right direction.

This project is .NET 5, though I'm not quite sure if that matters. When stepping through code in a Windows Form, the debugger keeps trying to step into the underlying methods for the controls, the form, and so on. I have no interest in that, as the problem I'm addressing has nothing to do with that. However, the debugger constantly tries, and when it can't find that source (it isn't all loaded on this machine), it asks me for it.

I'm pretty sure I turned this on, and I can't find any setting that will turn it off. In the Options for Debugging, General, there are options for Enable .NET Framework source stepping, which is unchecked, and Enable Just My Code which is checked (and I think that one is not relevant). Those are the only ones that seem somewhat related to the issue. I'm also not quite sure what to call this, so Google is not helpful.

I'm hoping somebody here can tell me how to turn this off.

Did you try resetting Visual Studio?

It's done through Tools -> Import and Export Settings. Then from there, you have options to reset Visual Studio or import settings etc.

Ah, the brutalist response. I hadn't tried that, so I did, and it worked. Of course, I went the whole hog and wiped out ALL my settings, so I had to reset a few things.

There has GOT to be a better way than that! Oddly, after a bit more Google searches, I have found a few things on how to turn this ON, but not a way to turn it back OFF.

I had some recent struggles trying to get the Disassembly window and the window for registers and memory. A lot of my time was spent dumping settings, importing settings, resetting ect. When something gets broken in Visual Studio, I find it less painful to just reset every damn thing.

I just spent some time comparing the various settings files I have saved (as it turns out, I have four of them, and I have no idea why, as I have only intentionally saved them twice). I used WinDiff to look at the differences...and eventually gave up. The differences between them are vast, multidirectional, and meaningless to me. It certainly looks like some update added a VAST number of settings, and that caused a new settings file to be created on two or three different occasions, but I'm not sure. Certainly, none of it appeared to be related to the current issue.

Yea, issues like that are common in Visual Studio. I wish Microsoft would simplify some of these settings.

I largely chanced into figuring out which property it is, and it turns out to be SUPER annoying. The option that regulates this appears to be this one from Debugging | General:

Suppress JIT optimization on module load.

If you check that, you are prompted to download source from the internet for controls, even if you have Enable .NET Framework Source Stepping disabled. Uncheck that, and those prompts promptly go away.

Unfortunately, that's not ALL that goes away, because you HAVE to have that checked to be able to step into your own DLLs. That may not be true in all cases. With it checked, you can step into release versions of your own dlls that you have referenced. I have not tested whether or not you can step into debug builds (without optimization), if you were referencing those, rather than the release builds.

This makes debugging Windows Forms applications that use your own dlls seriously annoying. I can understand that a person might WANT to step through the code behind a listbox, for various reasons, but most of the time you do NOT want to see the code behind that, or behind Object, or any other part of the framework...but you'll be prompted for it EVERY time.

I tried a couple more tests, and found that I haven't really solved anything, though I understand a bit more.

I'm working on a project with LOTS of dlls, both plugins (dynamically loaded) and non-plugins (referenced). Up until this point, I could freely step into release versions of either of those, so long as the version available was in sync with the source code. For example, if I changed a plugin, rebuilt, but didn't shift the resulting dll into the plugin folder, I couldn't step into the source code, because VS noted that the source code was newer than the code I was running. That is correct. Also, all those dlls had optimization turned on.

Now, with optimization turned on, I can no longer step into the source of any dll I wrote unless I turn off the property

"Suppress JIT optimization on module load"

This makes sense, since once it has been optimized, it is quite possible that the source is structurally different from the compiled dll. I don't know whether I had that property on or off in the past, but since it makes a whole lot of sense as to what it is doing, I would guess that I always had it on.

What has changed is that now, with that on, I am asked to download the source code for ALL the framework stuff whenever a step could take me there. That's the initial problem that started this thread.

Thinking that something I had done (which was to check then uncheck one other setting) had revealed a bug in VS, I erased all my settings once again so that I'd start out with a clean slate. That had no impact.

So, after all this, I'm left with this problem: Every time I step into code that makes use of something in the framework, I am now being prompted to download the source code for that part of the framework. I don't want to step through the framework source code to see how a listbox works, or see how Object is defined.

I can somewhat improve the situation by reverting to turning off all optimization, but I haven't done that for something like a decade, because I haven't needed to.

Something has changed such that I either have to turn off optimization or I can't step through just my code without stepping through everything MS has written as well. There is a chance that this was a VS update, but it is real nonetheless.

Any further suggestions?

Wow. That is a lot. Unfortunately, at this point you know more than I do. I've tried numerous times to actually enable the behavior you're trying to get rid of, ie stepping into framework code. I once got it to work but I have no clue what combination of the many things I changed actually caused it to work. I eventually gave up and now I just use the online reference source when I need to see Framework code. These settings are confusing as hell and I've never been able to figure out how to get them to do exactly what I want.

Well, I never found the cause, but I may have solved the problem. I might even be able to find the cause, eventually.

I had a second computer that was already set up with the same environment and the same projects, though a little out of date. I brought the projects up to date and confirmed that everything worked the way I remembered it. I was able to reference a release version, with optimization enabled, step into the source, and never be asked to step into MS source files.

I found a few settings different between the two systems, so I changed those.

Neither 'Enable Just My Code', nor 'Enable .NET Framework source stepping' was enabled on the working system, which was different. Those two are mutually exclusive, but I hadn't tried turning BOTH off, because I have some vague memory that the Enable Just My Code property was useful for something.

Another difference was that the working system didn't have 'Suppress JIT optimization on module load' checked. That property makes sense to me, as noted earlier, but it wasn't enabled, and the working computer was....working.

Setting those properties the same on the system that was having trouble did nothing useful. I could still step into the source of referenced dlls, but I was also asked about stepping into ALL MS source code, which was really annoying. Want to iterate through the keys in a dictionary? Oh, first you have to download the source for Dictionary.cs and step through that. Not good.

So, with the settings that looked applicable changed over, I had gained no ground. The next step was to export all settings from the working system and overwrite the settings on the system that wasn't working right.

That solved it, and that's a VERY unsatisfactory solution. Unless you happen to have the same development environment set up on a different computer, this solution won't do you any good at all.

A look at WinDiff on the settings from the two systems mostly just showed that I have a few extra packages installed on the good system, because I have been using that for a bit of web development that I don't do on the other system. That means that there are VAST blocks that exist on the one and not on the other. Wading through all of them to find the differences is more of a chore than I really want to undertake.