Minor Annoyances in VS2019

I've been using VS2019 for some things that I hadn't used it for in the past, and have come up with a couple minor annoyances that I'd like to confirm with others.

1) If you add a reference to some other dll or project, and choose Browse, the Recent list is ALWAYS empty. I have yet to see it contain anything, despite having just added a dll of my own creation. Navigating to the dll works just fine, but what's the point of a recent list if it has nothing in it...ever?

2) If you reference a Release version of a dll, you can't step into it while debugging. Frankly, this is how it really SHOULD work, because the release version won't have the symbol information that a debug version would have, and might have optimizations such that the code and the execution don't necessarily line up. However, in VS2010, there was no problem with stepping into release versions. In fact, this was done to an extent that was darn near magic, since you could dynamically load a release version dll from a folder that was not related to the project that created the dll, and VS would STILL let you step through the source code, complete with comments, which meant that VS was finding the project where the dll was created, and taking you to the source code from that project. I have yet to confirm that the same functionality is no longer available, but since VS2019 won't let you step into a referenced dll if the dll is a release build, I can only assume that it won't help you out any more than that for a dll that is dynamically loaded.

So, my question is: Is there a setting I have wrong such that the recent list holds nothing? Is there a setting that is preventing me from stepping into a release build?

I am unable to replicate the first issue.

I'm not familiar with referencing a release version to check the second issue.

Quote:

---

Originally Posted by dday9

I am unable to replicate the first issue.

---

Same here. The Recent list is populated for me, although I haven't tried it with my own DLL yet.

I haven't the time or inclination to test the second issue right now, but maybe at the end of the day.

Yeah my Recent list is populated fine too.

As for your second issue i would never come across it as i always add in the project to the solution if i want to debug it. Not sure what advantage you get from doing it your way.

Unless you have an old project where you only have the built files rather than the the project, but we use Git source control and i never have that issue anymore.


The thing that used to annoy me was the diagnostic tool, not sure if its still on by default, but i always turn it off in Options > Debugging > Enable Diagnostic Tools While Debugging and unticking it.

Plugins....adding the project to the solution would make little sense if your goal is third party plugins.

I'm amazed to hear that nobody else has seen the first issue. I'll have to try on some other computers to see whether or not it is specific to this system. At one point, I feel that there was something in the recent list, but that was just one time, and nothing has ever been in the recent list after that. Doesn't matter how recent, either. I can browse to something, add it, go right back in...and the recent list will be empty. I'll try on a different computer, or two, later today.

Sounds like you should try re-installing VS2019. Usually with freaky things like this where I'm the only one that seems to be having a problem and I just re-install and call it a day. If that doesn't work then it warrants further investigation.

Just discovered something interesting about my first point. I was not seeing the recent list being populated when adding a reference, and I'm still not....so long as I am working on a project migrated from VS2010 which targets FW4.X. When I start a new project targeting FW5.0, then the recent list is populated as expected. I haven't tested to see whether this is due to the targeted framework or the fact that the project was migrated, but it does appear to be consistent.

So, now I know why you folks were not able to replicate the problem: It depends on some underlying condition that I haven't quite tracked down.

I've found another little quibble that some of you might see as being a very ominous sign:

As you know, if you have a Control C, you can write either:

Me.C.someProperty

or

C.someProperty

VS would somewhat prefer the latter form, as the Me. is not necessary. You can change that behavior in settings, based on your style preference, but that's irrelevant to this point. What I found over the weekend is that you can't write this:

me.C

If you start off with a lower case m, intellisense won't even let you get to the period in "me." You can if you start with an upper case M, but with a lower case m, intellisense assumes you are writing something else and gives you the best alternative. You can get the "m" and the "e", but as soon as you type the period, you get some other option replacing the whole thing.

As annoyances go, that's really minor, but it feels like a C# thing, to me. I always write code in lower case to see that it case corrects. That's one of the big advantages of VB, because that case correcting is a valuable clue when working with lots of dlls, as I am doing. If the code doesn't case correct, you KNOW that you are doing something wrong. To not have me. case correct to Me., but instead to replace the me. with something chosen from intellisense, is decidedly annoying.