Author |
Topic |
|
mihnea
Junior Member
Romania
12 Posts |
Posted - Sep 06 2024 : 06:59:57 AM
|
When I switch to a new solution configuration, Visual Assist shows a modal popup which says "Reading solution projects" and sits there for up to 10 seconds. Can whatever processing that's happening there be moved to the background? VS on its own is bad enough at switching configurations, locking up for several seconds each time for no good reason; it would be great if VA didn't increase the pain in this case. :) |
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 09 2024 : 12:30:58 PM
|
I assume this is inside UE 5 based on your other thread? If so, then hopefully I will have a useful test case in hand soon. |
zen is the art of being at one with the two'ness |
|
|
mihnea
Junior Member
Romania
12 Posts |
Posted - Sep 10 2024 : 08:06:17 AM
|
It's in any large solution, but yeah, UE5 will definitely do it.
Also, I'd like to add that sometimes this popup never goes away. If you switch the startup project or the active configuration quickly a few times, it will show up with a delay and then stay there for almost a minute until VS eventually crashes. I just had this happen twice today. |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 10 2024 : 12:42:46 PM
|
OK, the dialog is confirmed. Now this has come up before, and last time this came up, it turns out that the dialog isn't modal. It's the actual process of reading the solution projects that is blocking the UI, and that was outside of our control. An old answer, it's here if you are interested:
https://forums.wholetomato.com/forum/topic.asp?TOPIC_ID=12159
not sure if its still the case or not, but crashing the IDE, this is a whole different problem!
Which version of VS2022 are you using? I am testing with VS2022 version 17.11.0 using a UE 5 solution, with VA 2530, running under Windows 10.
So far no sign of any form of crash. I have spent the last 10 minutes repeatedly changing the platform, as and when VS2022 lets me. I didn't do anything else with the IDE during this time, and did a lot of changes to the configuration, as you can imagine. Apart from this being slow, so far no sign of any problems here.
I was waiting for each change to complete before triggering the next one. Could it be you were trying to trigger a change before the last change had really taken? Or am I missing a key step? |
zen is the art of being at one with the two'ness |
|
|
mihnea
Junior Member
Romania
12 Posts |
Posted - Sep 11 2024 : 03:51:47 AM
|
I have VS 17.11.2, but I've seen this issue in every VS version I've used over the last year or so.
If the UI lockup happens for a different reason I guess it needs to be investigated separately. We've spoken to MS about it as well and sent them an ETW trace to see if they can improve the performance of VS itself when changing configurations. Still, it would be great to remove that popup, as it's not really providing any useful information to the user. Even if it doesn't block the UI, it still sits on top of the editor window and has to be moved away to be able to type stuff.
If the popup is waiting for a built-in VS process to finish, then the crash is probably not related to it, it's likely that whatever it's waiting for is actually crashing. I'll try to get some logs or crash dumps next time this happens, to figure out what's at fault. |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 11 2024 : 10:13:10 AM
|
A dump file would be very welcome. Clearly something is going wrong here, and causing regular crashes. Does my rather focussed test seem reasonable? Clearly it feels like changing the platform is a factor, but does anything else stand out in your memory for when the crash happens? |
zen is the art of being at one with the two'ness |
|
|
mihnea
Junior Member
Romania
12 Posts |
Posted - Sep 11 2024 : 10:31:12 AM
|
Yeah your test seems reasonable, that's all I was doing myself when it crashed: changing the startup project and then changing configurations. I'm not sure why it's crashing on my machine but not on yours, I'll try to figure it out. |
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Sep 11 2024 : 10:37:41 AM
|
If you have a bit of time to run a test, setting up a new, default test profile would be an interesting test. It is possible the trigger is related either to a setting on your system, another extension you have installed, or even some form of corruption in your default IDE profile.
If you want to try this can you first download the VS2022 specific installer for Visual Assist from:
https://downloadfiles.idera.com/WholeTomato/VA_X_Setup2530_0_x64.vsix
Next you will need extra details about the IDE install to create a test profile. To get these details, please open a Windows command prompt window, and inside the window run the command:
"%ProgramFiles(x86)%\Microsoft Visual Studio\Installer\vswhere.exe"
There will be a set of lines for each different version of Visual Studio that you have installed. For the version you want to install into, you want the "productPath", "dispalyName" and "installationVersion" lines, e.g.
productPath: C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\devenv.exe displayName: Visual Studio Professional 2022 installationVersion: 17.9.34607.119
You can then use the information from these three lines to make sure that the following command has the correct command line parameters. The values are:
/appidname: = displayName: /appidinstallpath: = productPath: /skuVersion: = installationVersion:
The "/skuName:" value is one of "Community / Pro / Enterprise", note for the Professional version it is "Pro", not the expected "Professional".
The working command, for VS2022, using the values above, is - split into lines to make it easier to read and edit:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\VSIXInstaller.exe" /appidinstallpath:"C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\devenv.exe" /skuName:Pro /appidname:"Visual Studio Professional 2022" /skuVersion:17.9.34607.119 /rootSuffix:"VATest" "C:\Users\%USERNAME%\Downloads\VA_X_Setup2530_0_x64.vsix"
The "rootSuffix" is the name of the test profile you want to install to, and this will be created if it does not already exist. The final parameter is the path of the VSIX installer for Visual Assist that you want to install. Once you have the command set up, the only parts you should need to edit are the skuVersion and the path to the VSIX file, can you please close all instances of Visual Studio and run this command.
Running this command installs VA into the test profile, but it does not load the test profile. If you created the test profile by installing VA, when you run the test profile it will be using the default IDE settings, without asking you which settings you want to use.
To now load the test profile you use the command:
"C:\Program Files\Microsoft Visual Studio\2022\Professional\Common7\IDE\devenv.exe" /RootSuffix VATest
To load your normal, default profile just load the IDE normally. To return to this test profile again, pass the /RootSuffix command line switch when loading the IDE. You can run both profiles at the same time, next to each other. In VS2019 and VS2022 the profile name will be shown just under the close button, in the top right hand corner of the main IDE window. If you export your IDE settings from your main profile you can them import them into the test profile.
Since you have a fairly simple pattern, it might make sense to try this. If there is no easy crash in the test profile then this will certainly tell us something. The trick will be working out what. But if the crash happens in the test profile as well, then this points much more clearly at a bug in VA, or just possibly in the IDE its self. But it will leave me wondering what I missed in my test. |
zen is the art of being at one with the two'ness |
|
|
mihnea
Junior Member
Romania
12 Posts |
Posted - Nov 22 2024 : 05:17:38 AM
|
Hi,
I haven't seen the crash again, but I still get that stuck dialog once in a while. The IDE is perfectly usable, but that dialog just sits on top. I can edit text, alt+g works, building and debugging work, but I have to move that dialog to another monitor to be able to use VS.
Regardless of why it's stuck there, can it just be removed? What value does it provide?
https://i.imgur.com/3VYyPXx.png
|
|
|
feline
Whole Tomato Software
United Kingdom
19014 Posts |
Posted - Nov 22 2024 : 07:25:11 AM
|
Are you aware of the trigger for this problem? Normally this dialog should only appear when VA and the IDE is loading the solution, or re-loading it after it was modified outside of Visual Studio, and the IDE has just detected this change. Even then it should only appear for a few seconds at most, just long enough for the solution to be read.
The dialog isn't doing anything, it is to let you know why the IDE isn't responding, since its busy. But since you can actually work around it, clearly something else is going on here.
When you say the dialog is stuck, does it disapear on its own? If not, how long does it stay for? A few seconds? A few minutes? Longer?
Assuming you are able to get rid of the dialog, how are you doing so? Or are you just closing Visual Studio to get rid of it? |
zen is the art of being at one with the two'ness |
|
|
mihnea
Junior Member
Romania
12 Posts |
Posted - Nov 22 2024 : 07:50:21 AM
|
The dialog appears when I open a solution in VS and normally disappears after a few seconds (VS is indeed busy on the UI thread so it appears to be not responding during that time). In some cases though, it stays open after the solution is read, and it never closes. I waited more than an hour in one case and it didn't go away, so clearly whatever it's waiting on never happens in those cases. I can move it out of the way and use the rest of the IDE just fine, but I couldn't find a way to close it. The only solution is to restart Visual Studio. |
|
|
|
Topic |
|
|
|