Vsvim: Cannot change block caret color

[farzadmf]

Hi,

Today, I'm facing an issue with VsVim where my block caret is now black. I tried to set the color in Item Colors in settings, but the weird thing is that when I change it and click OK, the color is still black, and when I come back to the settings window, the setting has been reverted back to its previous value.

Example:

1. I open VS, the caret in VS is black
2. I go to the settings and change Block Caret Background (which is now Black) to Yellow (just to test)
3. I click OK, the caret is still black
4. I come back to the settings and Block Caret Background is set to Black again!

One thing that might be important is that the first time I opened VS today, I saw an exception saying something like "the error may be because of an exception"; I'm used to exceptions appearing from time to time, but maybe this one caused something to change and now VsVim cannot save its settings?!

I appreciate if you help me

[ricksladkey]

I'm sorry to hear about that. Can you perform a couple of experiments for me to narrow down where the problem is?

First, can you successfully change other VsVim colors from the settings window, like the command margin foreground/background?

Second, does trying to change the block caret background color through the Visual Studio settings work or behave any differently?

Tools -> Options -> Environment -> Fonts and Colors -> Display Items -> VsVim Block Caret -> Item Background

[adamskt]

I ran into the same situation today, and the VsVim options do not appear in the Fonts and Colors "Display Items" listing in Tools -> Options -> Environment:

I did see the plugin exception prior and restarted Visual Studio. The relevant lines from ActivityLog.xml are:

CreateInstance failed for package [Vim.VisualStudio.VsVimPackage, VsVim, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null]Source: 'mscorlib' Description: Could not load file or assembly 'file:///c:\users\kellyadams\appdata\local\microsoft\visualstudio\15.0_f847dbb5\extensions\42ka1uwz.afy\VsVim.dll' or one of its dependencies. The system cannot find the file specified. System.IO.FileNotFoundException: Could not load file or assembly 'file:///c:\users\kellyadams\appdata\local\microsoft\visualstudio\15.0_f847dbb5\extensions\42ka1uwz.afy\VsVim.dll' or one of its dependencies. The system cannot find the file specified.

Visual Studio version info:
VisualVersionInfo.txt

[adamskt]

FWIW, a uninstall/reinstall of the VsVIM VSIX has remedied the issue.

[farzadmf]

Thank you @ricksladkey for your answer, and thank you @adamskt for pointing out the problem. That's exactly the problem that I had, and it was very confusing for me that the options disappeared from Fonts and Colors!

But anyway, as suggested by @adamskt , I uninstalled/installed VsVim, and it seems to be fine now.

I can close this issue if you guys don't want to keep it open to investigate

[mattscully]

I'm wondering if this might be happening for everyone that uses the Dark theme and just upgraded to the latest version of VsVim. It happened for me, too. It could be that a fix is still worth it, unless it is recommended for everyone to have to reinstall the extension.

[ricksladkey]

@mattscully I definitely use the dark theme (see my caret colors above) and didn't run into this problem myself. However, people who do use the dark theme are much more likely to notice the problem if it occurs because the the default foreground/background caret colors are reasonable for a light theme but terrible for a dark theme. So someone with the light theme might be having the problem (no longer able to control VsVim fonts and colors), but not immediately affected by it because the defaults look "ok".

[ricksladkey]

@farzadmf Please leave this issue open until we determine what the conditions are that produces it. If there is some way of avoid the burdensome uninstall/reinstall, that would be preferable to a workaround.

@jaredpar Does this symptom ring any bells, i.e. fonts and colors issues with extensions? I believe at the "fonts and colors" level, the only obvious change from 2.5 to 2.6 is that the EditorFormatDefinition for vsvim_blockcaret changed to allow the foreground to be customizable:

index 34f18c8e..4de424bd 100644
--- a/Src/VimWpf/Implementation/BlockCaret/BlockCaretFormatDefinition.cs
+++ b/Src/VimWpf/Implementation/BlockCaret/BlockCaretFormatDefinition.cs
@@ -18,8 +18,8 @@ namespace Vim.UI.Wpf.Implementation.BlockCaret
         internal BlockCaretFormatDefinition()
         {
             DisplayName = "VsVim Block Caret";
-            ForegroundColor = Colors.Black;
-            BackgroundCustomizable = false;
+            ForegroundColor = Colors.White;
+            BackgroundColor = Colors.Black;
         }
     }
 }

[Wojnach]

I have the same issue. Reinstalling VsVim didn't revert it back to normal.

[ricksladkey]

Can anyone report whether VsVim "works at all" when the "fonts and colors" are messed up? That is, can you issue normal mode commands, does the command margin appear, etc.?

It sounds like VsVim is partially loaded, i.e. loaded enough that the VsVim UI is available, but not loaded enough that MEF resolves VsVim's editor format definitions.

Since one report above shows a CreateInstance error for the VsVim package (with a "file not found" resolving assemblies related to VsVim.dll), it could be helpful to have a full activity log for a Visual Studio startup on an installation that exhibits the problem.

[jaredpar]

For anyone who saw the dialog about an exception in an extension can you do the following:

1. Install this extension https://marketplace.visualstudio.com/items?itemName=MadsKristensen.ClearMEFComponentCache
2. Under Tools menu there will be an option "Show MEF Errors"

Can you paste back the output of that menu? If there is a composition issue that will have the relevant log and give us the info we need.

[farzadmf]

Hey @ricksladkey, I'm not sure 100%, but I think VsVim was working properly; only the caret color was weird

@Wojnach For me, re-installing VsVim resulted in the options to become available, and then I needed to change the color manually

And @jaredpar , thank you for the suggestion, I think the extension would be useful in any case

[Wojnach]

Did the default ForegroundColor switch from Colors.Black to Colors.White in the commit mentioned above? Those default colors produce the black block caret for me.

If I reinstall VsVim on VS2017 the Block Caret Background defaults to the color (240, 240, 240). This does not happen if I reinstall it on VS2015.

Below is a MEF errors dump from VS2015. Note the Vim.VisualStudio.Vs2017.dll. I don't have VS2017 on this computer (anymore):

----- Catalog construction errors -----
Error #1
Microsoft.VisualStudio.Composition.PartDiscoveryException: ReflectionTypeLoadException while enumerating types in assembly "C:USERSHERCAPPDATALOCALMICROSOFTVISUALSTUDIO14.0EXTENSIONS0F2C1IR5.JDYVim.VisualStudio.Vs2017.dll". Results will be incomplete. ---> System.Reflection.ReflectionTypeLoadException: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
at System.Reflection.RuntimeModule.GetTypes(RuntimeModule module)
at System.Reflection.RuntimeModule.GetTypes()
at System.Reflection.Assembly.GetTypes()
at Microsoft.VisualStudio.Composition.PartDiscovery.CombinedPartDiscovery.GetTypes(Assembly assembly)
at Microsoft.VisualStudio.Composition.PartDiscovery.<>c__DisplayClass26_0.b__0(Assembly a)
--- End of inner exception stack trace ---
System.IO.FileNotFoundException: Could not load file or assembly 'Microsoft.VisualStudio.Text.UI, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
File name: 'Microsoft.VisualStudio.Text.UI, Version=15.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'

[jaredpar]

@Wojnach

Thanks for posting that. That particular error is benign. I will look and see if I can make this go away. But at the same time it's not causing any issues here.

[ricksladkey]

@Wojnach The old foreground color was used as the background the old background color was unused. VsVim now uses the foreground color for the foreground and the background color as the background, which makes a lot more sense. The default color selection looks correct only with the light theme.

The net effect with the old version and the new version is that the actual default background color of the caret was and is still black. This was always bad for the dark theme, but at least you could change it.

The good news is that you can actually read the character under the caret (with any theme) if you choose appropriate contrasting colors. The problem (experienced by some but not all users) is that due to some Visual Studio issue, the VsVim fonts and colors don't exist and therefore cannot be set.

The upshot is that almost all users will have to tweak the caret color for the best results.

I only have access to a limited number of machines and the problem is not showing up on those machines so I am trying to reconstruct what could be happening on the installations that exhibit the problem. I feel pretty crummy about the whole situation, since the idea was to improve the caret colors for everybody not make the caret worse for anybody.

[kub1x]

For me, the issue occured after upgrading VS2017 to v15.8.7 (not sure from what version, but think there was a bump in minor version number too). Might be VS to blame..? Reinstalling the plugin solved it for me and the customisation works as intended. This way it does make more sense. Much obliged Rick!

[jaredpar]

Chatted with a few people and to fix the theming issue we need to get themed colors for this definition. Essentially a color which will change based on the theme. The process is documented at this link:

https://docs.microsoft.com/en-us/visualstudio/extensibility/internals/color-theming-tools?view=vs-2017

I haven't had a chance to digest this fully yet. At a glance though it looks like it's pretty straight forward.

[ricksladkey]

@jared Theming is a good idea, but will only reduce the number of users who have to configure VsVim fonts and colors. The bug here is that it is impossible to set the colors. In other words, the VsVim fonts and colors should "show up" in Tools -> Environment -> Fonts and Colors without having to uninstall and reinstall the VsVim extension.

I am more and more convinced that this is a MEF issue and would really like a complete Visual Studio activity log for a system exhibiting the problem. See the first report from @adamskt above.

[adamskt]

@ricksladkey I did save my ActivityLog.xml, I hope the signal/noise ratio isn't too high for you :)
ActivityLog.zip

[jaredpar]

@adamskt thanks for providing that. That gives a clue to what's going on. The MEF error log would help me narrow it down to a more specific area. Can you do the following:

1. Install this extension https://marketplace.visualstudio.com/items?itemName=MadsKristensen.ClearMEFComponentCache
2. Under Tools menu there will be an option "Show MEF Errors"

Can you paste back the output of that menu?

[jaredpar]

@ricksladkey

I am more and more convinced that this is a MEF issue

That was my initial thought as well. The data though is a bit confusing. Here is the first error from @adamskt log:

 Exception occurred while loading assembly Vim.VisualStudio.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null: System.IO.FileNotFoundException: Could not load file or assembly 'Vim.VisualStudio.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'Vim.VisualStudio.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
   at
 System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at
 System.Reflection.RuntimeAssembly.nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at
 System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks)
   at
 Microsoft.VisualStudio.ExtensibilityHosting.FaultCatchingAssemblyLoader.<>c__DisplayClass17_0.<LoadAssembly>b__0(AssemblyName assemblyNameParam)

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
.;vs.platform.extensibilityhosting.assemblyloadexception.AssemblyFullName=Vim.VisualStudio.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null;vs.platform.extensibilityhosting.assemblyloadexception.AssemblyPath=file:///C:/USERS/KELLYADAMS/APPDATA/LOCAL/MICROSOFT/VISUALSTUDIO/15.0_F847DBB5/EXTENSIONS/42KA1UWZ.AFY/Vim.VisualStudio.Shared.dll;vs.platform.extensibilityhosting.assemblyloadexception.FusionLogEntry=WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
;vs.platform.extensibilityhosting.assemblyloadexception.ExceptionType=System.IO.FileNotFoundException;vs.platform.extensibilityhosting.assemblyloadexception.ExceptionMessage=Could not load file or assembly 'Vim.VisualStudio.Shared, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.;vs.platform.extensibilityhosting.assemblyloadexception.ExceptionStackTrace=   at

Two interesting take aways from that:

1. The load of Vim.VisualStudio.Shared is done via Load(AssemblyName). That means VS fully expects the directory holding the VsVim binaries to be in the current probing path else it would have done a LoadFrom(string).
2. The exception is FileNotFoundException which suggests it's not actually in the probing path. That or the extension is only partially installed.

One possibly explanation for this is that it's actually a pkgdef problem. Essentially VS is seeing data in the pkgdef (loaded statically not with the assembly) that causes it to do a MEF query before MEF has loaded VsVim. Been a long time since I've seen that though. I've done what checking I can to eliminate that possibility.

I'm going to ask around and see if I can understand a bit better how MEF composition works in more recent versions of VS. Too much of my mental model is built around the VS2010 version which is substantially different than the new one.

[ricksladkey]

@adamskt Thanks for the log. Ha, ha, yes, there are literally 20,000+ stack frames in that activity log. However, it call all be summarized by:

• Some problem loading Vim.VisualStudio.Shared or one of its dependencies
• Likely the same problem loading Vim.UI.WPF
• Some other problem loading the VsVim package

Unfortunately, I did not gain any major insight into what is going wrong.

[eviltobz]

Hmmm, I was having this problem with the colours all sticking to black whilst running the dark theme. Restarting Studio didn't help me change the colours, but just installing that MEF error tool & re-restarting Studio fixed the problem for me - it suddenly went back to a varied bunch of colours which I presume that I set up some time in the past, and I was able to change them to something else successfully too.

[ricksladkey]

@eviltobz I think your observation supports the idea that there is an ordering difference (effectively a race condition) during the initial caching of the MEF graph. Simply repeating the generation of the MEF graph, either by clearing the MEF cache, uninstalling and reinstalling VsVim, or installing some other extension might successfully do one or more steps in a different order and avoid the race condition.

[ricksladkey]

Closing this issue as the symptoms were not related to the new functionality at the time.

If you experience an error similar to what is reported above, and it cannot be fixed by uninstalling and reinstalling VsVim, please open a new issue.