Visual Studio 2022 updated itself to the latest version Version 17.3.3.  

I then had some problems with finding references and responsiveness, so I installed the latest version of Visual Micro (Release 22.09.05.0) via the visual studio 2022 extension menu. This caused visual studio to freeze. 

Before this happened I was running the most recent prior version of Visual Studio and Visual Micro -- I had just installed the special release of VM that included the timing change for serial reads and serial read timeouts, and this had been working fine before the upgrade of Visual Studio.

I uninstalled everything and started fresh with visual studio 2022 community edition. Everything worked fine. I installed Visual Micro => the same problem occurred, and that's where I'm stuck now.

Visual Micro is the only extension installed, and once it is installed visual studio is completely nonfunctional,  even with no solution loaded.

Symptoms are that top level menu dropdowns do not appear, and the menu name doesn't even become selected. Code does not display in code windows. The explorer is navigable but I cannot open code files with it. Basically nothing happens in response to most clicks on visual studio gui elements.  Occasionally a drop-menu opens when I click somewhere that's NOT a menu selector, and when that happens the drop menu is way off to the left side of my screen, nowhere near the window in which it should appear.

When I open a c++ project I don't get errors, but most things don't work. I can still exit, though...

When I open a c# .net project I do get errors as shown in the attached image.

I cannot disable the visual micro extension because I can't get the extension menu to appear. If I launch visual studio in safe mode, everything runs normally. However, it doesn't appear possible to disable or uninstall an extension in safe mode, so I'm limited to uninstalling and re-installing. 

I'm going to roll back to an earlier release of Visual Studio and possibly to an earlier release of Visual Micro, but it would be good if this could work.   

VS version 17.3.3 is significantly faster than previous versions, and it has several nice improvements (e.g., multi-row tabs) that make it desirable...

Thanks for any help!

Simon@Visual Micro wrote on Sep 8^th, 2022 at 9:25am:


Repair => no changes.

I'm glad to hear that you are running this combination without difficulties -- with that information I will pursue the problem at my end and update this forum with the results.

Can you confirm if you have the English Language pack installed in Visual Studio?  (Tools > Get Tools and Features > Language Packs)

Update #2 for today:

After two full days of exploration, I am giving up and will revert to an older release of visual studio.  

Here's where I got to:

I was able to show that the event log errors referred to in my previous message are not specific to visual micro -- they now occur for me when any extension is enabled or disabled (or installed or removed). 

I have traced them to a known (recurring) problem that can be caused by several things, including certain MSFT components that have broken reference resolution in multiple releases. There is also some story here about different behavior for MSBuild, devenv.com, and devenv.exe.

These error messages may still be relevant to Visual Micro because one reported cause for this error is an extension that was not correctly ported to VS2022. Some of the VS2022 breaking changes apparently involve dlls (e.g., EnvDTE) with no workaround for backward compatibility. Some extensions have reportedly been forced to branch in order to handle both vs 2022 and earlier versions. 

Here are a couple of links I found. I'm sure you'll be able to tell right away whether they are relevant or just noise.

https://developercommunity.visualstudio.com/t/envdte-unable-to-use-in-packages-o...

https://github.com/dotnet/ResXResourceManager/issues/415

= = =
In the meantime, I rolled back to the interim release of Visual Micro and found no difference in behavior.

I then installed a large number of other optional packages from the visual studio installer. This made no difference.

I then took a solution folder containing a moderately complex embedded application and deleted every visual studio & visual micro artefact (.vs, _vm, vsproj, user, and .sln). I told visual micro to open it as an existing arduino project. An sln file was created, and *that* file can be double-clicked without causing the crash. 

However, I wasn't able to manually rebuild the project structure, which had multiple projects for libraries in a library folder as well as lots of included and non-included .h, .cpp. and .c files. Even the .ino file wasn't recognized as included code, so syntax highlighting was missing.  

I tried instead removing things one by one to identify what triggers the bad behavior, but I was unable to find anything that made a difference on its own. 

I then attached a debugger and watched an instance of devenv fail when I double click on the minimal sln file for a winforms solution. Basically devenv gets stuck and spins waiting for a thread to return and reading the message queue. If I click around in the interface it doesn't show that anything is happening, but it does occasionally throw exceptions like these:

exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.MissingMemberException' in Microsoft.VisualBasic.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.MissingMemberException' in Microsoft.VisualBasic.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.MissingMemberException' in Microsoft.VisualBasic.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.MissingMemberException' in Microsoft.VisualBasic.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.MissingMemberException' in Microsoft.VisualBasic.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.Runtime.InteropServices.COMException' in mscorlib.dll
Exception thrown: 'System.MissingMemberException' in Microsoft.VisualBasic.dll
Exception thrown: 'System.Threading.Tasks.TaskCanceledException' in mscorlib.dll
Exception thrown: 'System.Threading.Tasks.TaskCanceledException' in mscorlib.dll
Exception thrown: 'System.Threading.Tasks.TaskCanceledException' in mscorlib.dll
Exception thrown: 'System.Threading.Tasks.TaskCanceledException' in mscorlib.dll
Exception thrown: 'System.Threading.Tasks.TaskCanceledException' in mscorlib.dll
 

I'm sure with a day of effort in ETW I could find out what's blocking it or where it's spinning, but since the problem doesn't appear to be anything I can fix on my end I'm giving up.

My guess right now is that it works for you because you have something on your system that I'm missing, like an older version of a dll in your gac, or perhaps an enterprise version was installed with load testing assemblies.

I'm willing to try again if you come up with something, but right now I've lost two work days and I have looming deadlines, so I'm going to try to roll back Visual Studio. 

All in all, this has been an somewhat harrowing experience.   

Tim@Visual Micro wrote on Sep 10^th, 2022 at 4:08pm:


// Ah, the old cross-thread control issue bites again!
If (InvokeRequired)
{ BeginInvoke(...);}

That was it.  Thank you!  

I thought I had tried every combination of UX settings, but that one had eluded me. 

I don't normally use the "AutoVis All" setting because it hides the serial terminal options when coding for the desktop, and because it takes up one row more than I need or want when working on embedded projects.

I might mention that I always find the operation of the interface element selection process confusing because the language "Toolbar Visibility" suggests that checked elements will be visible when working embedded, and automatically become invisible when working on desktop solutions. However, the opposite is true: the checked elements will be HIDDEN, either manually or with automatic switching based on code detection. Also, there's no checkmark to show whether Auto All or Manual All is set. I understand that this approach may have advantages, but I've seen posts on other sites suggesting that others are also confused by the nomenclature and the functionality.  In some future version, on-off-auto switches might make things a wee bit clearer.  

Thank you again for figuring this out!!!!!   

Tim@Visual Micro wrote on Sep 10^th, 2022 at 7:09pm:

That's what I meant: An "arduino" project  vs. a "non-arduino" project. I personally wouldn't mix them in a single solution even though I'm usually writing both ends of the connection at the same time. In my experience doing so screws up reference tracking (which is already wonky when writing for arduino) so I just think of them as -ino solutions and non-ino solutions

Quote:

Right. Well, suppose I want to see the serial port all the time, and the USB Type only when I'm in an arduino project, and none of the others, ever. What am I supposed to check? And how am I supposed to know whether I am in Auto All or Manual All mode, or whether there's another mode,since neither of those two show any indication that they are active. (OK, I actually know that these are not modes, but only since you told me...)

Sometimes when I put a check mark next to one of the toolbars, the toolbar disappears. Other times the check mark goes in but nothing happens.  Sometimes check marks appear or disappear without me having checked them.  You can see why this might be a bit confusing.

Quote:

I would have understood better if those were called something like "Turn All On" and "Turn All Off." Especially if they turned on / off all the check marks and did not close the menu, so I could see what had happened. 

But in fact, I don't think the described behavior is exactly what's happening. For example, I just clicked Auto All =>  Programmers and Board options become unchecked whereas the others all become checked. I then clicked Manual All => Programmers and Board options became checked and everything else became unchecked. Nothing change in terms of which toolbars are displayed (I have an arduino-style project open).  And I have no idea what to expect when I switch to a c# project. Will I see just Programmers and Board Options, which are checked? Or will those be hidden and the unchecked ones will be visible? My original expectation was that if I clicked Auto All, all of the toolbars would be set to Auto => they would appear for Arduino and disappear when not Arduino. However, the fact that Auto All leaves several elements unchecked makes it seem unreasonable to expect this. 

I know I sound picky. There's a reason for that: I'm a biophysicist and physician, and for many years I designed hospital system interfaces (before I went to  Microsoft). The medical field is full of documented deaths caused by user confusion, so I can't help thinking about it. Thankfully we don't have to worry about that kind of thing here!!!


Quote:

Since you had mentioned that the VS UX unresponsiveness problem depended on whether something was executing on the UI thread vs another thread, I was just making an oblique reference to the canonical way of writing to objects owned by one thread from a task that's running on another thread (i.e., by passing a delegate and requesting that the function be executed on the destination thread, using beginInvoke()). Sometimes synchronization contexts are helpful, of course, but when it comes to the UI thread they really just call Invoke or beginInvoke under the hood.

Where I come from (imagine 2000 developers in multiple countries all working on a single distributed application) often it's hard to know where a particular function will be executed, since it could be called from code running in any task on any thread. Since functions intended to be called from the UI thread might someday end up being called from a task thread, any call that needs to touch an owned element (especially any visual control) just gets reflexively wrapped in an (if InvokeNeeded) statement. 

One of the nice things about being at Microsoft was that the entire sourcecode for every version of every product was all available in a single source manager. It's quite interesting how much coding style varies across teams even with style cop turned on everywhere. Heavily visual applications are just completely different from those without much of a UX. 

If you disassemble a heavily visual application like Visual Studio, you'll see control.beginInvoke() everywhere, since virtually no work is done on the UI thread but the result of virtually all work is to change something in the UI.

Thank you again for finding the problem so quickly!!

Just to update we have published the latest release (22.09.05.4) which will work around this issue.

It is available in Extension Manager (VS2022), or for direct download from the top of the board below:
https://www.visualmicro.com/forums/YaBB.pl?board=VS_ARDUINO_EXT_RELEASES