Options fail to deserialize

[davkean]

Hit this while debugging, I think it gets swallowed later so not sure of the impact:

The string is was trying to parse was "True", which isn't valid XML.

System.Xml.XmlException: 'Data at the root level is invalid. Line 1, position 1.'
    System.Xml.dll!System.Xml.XmlTextReaderImpl.Throw(System.Exception e)    Unknown
    System.Xml.dll!System.Xml.XmlTextReaderImpl.Throw(string res, string arg)    Unknown
    System.Xml.dll!System.Xml.XmlTextReaderImpl.ParseRootLevelWhitespace()    Unknown
    System.Xml.dll!System.Xml.XmlTextReaderImpl.ParseDocumentContent()    Unknown
    System.Xml.dll!System.Xml.XmlTextReaderImpl.Read()    Unknown
    System.Xml.dll!System.Xml.XmlReader.MoveToContent()    Unknown
    System.Xml.Linq.dll!System.Xml.Linq.XElement.Load(System.Xml.XmlReader reader, System.Xml.Linq.LoadOptions options)    Unknown
    System.Xml.Linq.dll!System.Xml.Linq.XElement.Parse(string text, System.Xml.Linq.LoadOptions options)    Unknown
    System.Xml.Linq.dll!System.Xml.Linq.XElement.Parse(string text)    Unknown
>    Microsoft.VisualStudio.LanguageServices.CSharp.dll!Microsoft.VisualStudio.LanguageServices.CSharp.Options.AutomationObject.SetXmlOption(Microsoft.CodeAnalysis.Options.PerLanguageOption<Microsoft.CodeAnalysis.CodeStyle.CodeStyleOption<bool>> option, string value) Line 687    C#
    Microsoft.VisualStudio.LanguageServices.CSharp.dll!Microsoft.VisualStudio.LanguageServices.CSharp.Options.AutomationObject.Style_PreferIntrinsicPredefinedTypeKeywordInDeclaration.set(string value) Line 521    C

[balajikris]

this is what @jasonmalinowski and @CyrusNajmabadi feared would be a breaking change with the work i did for Intrinsic type keyword/Framework type code style. see comments here #13132

I bet the scenario is reading values from an existing user settings file, where this was a boolean option, but is now a more complex string (with enforcements etc.). So, it won't parse well. The net effect i believe is that we lost your preference for this setting and chose the default instead, which would be that you prefer the intrinsic type keyword and enforcement level is None (so you won't be bothered if your code is not compliant). (Note that there was never a prefer framework type in VS2015).

This could be made better to whatever we prefer, by choosing a good default setting. But, if we cannot afford to lose the user setting at all, then we should provide some form of back compat to retain the existing setting.

[Pilchie]

I'm seeing that this is causing the keyword/framework option is never getting persisted, and ends up back at Framework type every time I restart VS :(

[balajikris]

Spoke offline with @Pilchie . I'm unable to reproduce this behavior where the settings change fails to persist. If there is a consistent repro, please ping me.

Otherwise, for the issue reported originally in this bug, you'd encounter the setting didn't migrate over for the first time and it would start working after you set it the first time.

[jasonmalinowski]

Indeed, the assumption here is this is a migration issue, and won't be a problem going forward.

[jasonmalinowski]

Ah, this is migration from previous VS versions. Grr.

[Pilchie]

Did we get to the bottom of this?

[davkean]

It was still occurring on my box when I left.

[Pilchie]

@davkean is back!

[davkean]

This was also occuring with side-by-side instances of VS as well, so where is this "bad" data coming from?

[Pilchie]

See #15705 - it looks like roaming settings can roam a value from VS 2017 back to VS 2015 and vice versa where we used the same key, but now store a different type.

[jmarolf]

fixed with #16373