Roslyn: Visual Studio is wrongfully suggesting that I replace "var" with "string", and ignoring my preferences / the preferences are super limiting.

[vsfeedback]

In Visual Studio 2017, I have it set to prefer "var" when variable type is apparent, but the following line still generates the IDE0008 message:

var x = "Bacon ipsum dolor amet . . . ";
Console.WriteLine(x);

I'm really not sure how the variable type could be any more apparent.

The problem is that it's getting confused by the "For built-in types" preference (which I want to not be var for value types such as int, etc.).

Please fix this by giving us more granular control over when to prefer var and when to prefer an explicit type (i.e. separting each into 'for built-in value types' / 'for built-in reference types', and 'when the object type is apparent (for value type objects)' / 'when the object type is apparent (for reference type objects)', etc.) -- Another distinction that might need to be made is enums...

Like people generally want to do stuff like this:

// Built-in value types
int i = 5;
float f = 5.0f;
double d = 5.0d;

// Enum (also a value type, but there's no reason to put a class name on the same line twice, that's just dumb):
var color = ConsoleColor.Red;

// Built-in reference types
var myString = "Bacon ipsum dolor amet . . . ";

// Constructor: Object type is apparent.
var o = new MyObject() 
{ 
    SomeProperty = ConsoleColor.Red,
    SomeOtherProperty = "Bacon ipsum dolor amet . . . "
};

// Factory: Putting the type name here doesn't provide any value, because it's either an interface or an abstract class...
var cheeseBurger = BurgerFactory.BuildMeANewBaconCheeseBurger(...);

The current configuration options fall super short of allowing for this, and basically makes them unusable, because they will almost always recommend the opposite of what you want.

_This issue has been moved from https://developercommunity.visualstudio.com/content/problem/127687/visual-studio-is-wrongfully-suggesting-that-i-repl.html
VSTS ticketId: 506375_
_These are the original issue comments:_
(no comments)
_These are the original issue solutions:_
(no solutions)

[sharwell]

💭 It sounds like the only request here is the ability to treat string separately from other built-in types for the purpose of the "for built-in types" preference. If that is the case, then I would be in favor of closing this as won't fix for the following reasons:

1. I have seen multiple teams extensively preferring to treat built-in types by using var, and others preferring to treat built-in types by their built-in type names. In all these cases to date, teams found it acceptable to treat string as a built-in type uniformly.
2. The analyzer infrastructure allows users to create an custom analyzer which applies any modification to the base rules that someone could desire, and two open source implementations of such a rule are available under permissive licensing terms to serve as examples for this.

I strongly believe that the currently available settings cover the majority of desired user scenarios, and attempting to take this further will only result in a tail of one-off options being defined to cover the isolated special cases. The special cases will inevitably be poorly tested due to combinatorial explosion, while still failing to meet the final needs of 100% of users.