I've been using VS2010 for working on a plugin system. The main project references a few of my own dlls (three or four), and everything else is dynamically loaded plugins. I recently moved to VS2019, and can't go back because I updated some technology that requires at least FW 4.5, so VS2010 is out of the question.
In general, I like VS2019, but there have been a few annoyances. When adding references, the recent list is always empty for me, though others say it works fine for them.
Unfortunately, a newer annoyance just seems ugly, for my situation: In VS2010, you could step into the source of any dll, referenced or not, and the version (Release or Debug) didn't seem to make any difference. That never made sense to me, as I don't see why I could step into a release version, but what has to happen to be able to step into dynamically loaded dlls is even more impressive. That behavior has changed with VS2019. Regardless of whether the main program is in release or debug, I can't step into a dll that was built to release version. I have yet to try this for the plugins, but I fear that it will be the same case.
This makes no sense to me, but it will be particularly painful. I reference a dll of my own making, and whether I reference release or debug determines whether or not I can step into the source code. That means that everything has to be built as debug versions to allow for debugging, and then everything has to be changed over to release versions at some later date. That's annoying, but it's only a few dlls. However, if the same is happening for plugins (which I currently can't test), the situation becomes FAR worse because there are dozens of them.
It clearly doesn't matter all that much, since VS2010 allowed you to step into the source regardless of version. Showing the source for release versions is insignificant beside what has to happen to allow stepping into plugins. Is it really no longer possible? That would be a significant step back in utility for VS, in my case.
If it is the case, how does one simply toggle back and forth between the versions? If the main project is in debug, I want the dlls to also be in debug. If the main project is in release, I want the dlls to also be in release. When it comes to the plugins, that's a different matter, as they are all just found in some folder in the Documents. They aren't necessarily associated with the projects that built them, so the very fact that VS2010 allowed stepping into that code meant that it had to note the name of the DLL, note that a project existed on the same computer which built such a dll, and assume that the source in the project was the source for the dll. To some extent, that's not quite as impressive as it sounds, as the dll will have a fingerprint that will match exactly to the project, but VS is making quite a leap to go from a dll sitting in a folder to a project sitting somewhere else on the HD and just step right on into the source code. If I now have to deploy all debug plugins just because VS has decided to become pedantic in it's old age, that's a problem for me.
In general, I like VS2019, but there have been a few annoyances. When adding references, the recent list is always empty for me, though others say it works fine for them.
Unfortunately, a newer annoyance just seems ugly, for my situation: In VS2010, you could step into the source of any dll, referenced or not, and the version (Release or Debug) didn't seem to make any difference. That never made sense to me, as I don't see why I could step into a release version, but what has to happen to be able to step into dynamically loaded dlls is even more impressive. That behavior has changed with VS2019. Regardless of whether the main program is in release or debug, I can't step into a dll that was built to release version. I have yet to try this for the plugins, but I fear that it will be the same case.
This makes no sense to me, but it will be particularly painful. I reference a dll of my own making, and whether I reference release or debug determines whether or not I can step into the source code. That means that everything has to be built as debug versions to allow for debugging, and then everything has to be changed over to release versions at some later date. That's annoying, but it's only a few dlls. However, if the same is happening for plugins (which I currently can't test), the situation becomes FAR worse because there are dozens of them.
It clearly doesn't matter all that much, since VS2010 allowed you to step into the source regardless of version. Showing the source for release versions is insignificant beside what has to happen to allow stepping into plugins. Is it really no longer possible? That would be a significant step back in utility for VS, in my case.
If it is the case, how does one simply toggle back and forth between the versions? If the main project is in debug, I want the dlls to also be in debug. If the main project is in release, I want the dlls to also be in release. When it comes to the plugins, that's a different matter, as they are all just found in some folder in the Documents. They aren't necessarily associated with the projects that built them, so the very fact that VS2010 allowed stepping into that code meant that it had to note the name of the DLL, note that a project existed on the same computer which built such a dll, and assume that the source in the project was the source for the dll. To some extent, that's not quite as impressive as it sounds, as the dll will have a fingerprint that will match exactly to the project, but VS is making quite a leap to go from a dll sitting in a folder to a project sitting somewhere else on the HD and just step right on into the source code. If I now have to deploy all debug plugins just because VS has decided to become pedantic in it's old age, that's a problem for me.
