Add an "unmanaged"/"blittable" generic type constraint and use it to allow generic pointers and related features. Related post by Eric Lippert:
http://stackoverflow.com/questions/7551461/c-sharp-generic-constraint-where-is-not-class/7557040#7557040

The end result would allow this sort of code:

unsafe void DoSomeStuff<T>() where T : unmanaged
{
T t = new T();
T* tPointer = &t;
T* aBunchOfT = stackalloc T[100];
var tSize = sizeof(T);
byte* aBunchOfBytes = stackalloc byte[tSize * 100];
T* aBunchOfCastedT = (T*)bunchOfBytes;
}

Performance critical generic data structures, particularly those using preallocated pools of memory, would be a good example use case for this.

Currently, a data structure using pointers to represent data would either need to be type specialized or its users would end up casting pointers. Type specialization hurts code reusability. Requiring external pointer casts is error prone and infects other code with unsafe code requirements. Generic pointers make it easy to modularize the reusable unsafe bits, allowing relatively-low-maintenance drop-in replacements for platforms that don't allow unsafe code.

Adding support for an unmanaged constraint and generic pointers would make reusable unsafe code cleaner and more reliable.

When you think of it, its silly that methods by default can only return one value, but can take many arguments. Often times you want many return values, but it would be too painful to create classes/structs for each set, so often developers decide to then use ref or out parameters.

Instead what if method/function calls could return many values without the need to define a class/struct.
This example is a bit contrived but this shows the power of the fact that error information and values can easily be returned al at once.

Syntaxt like:

private {int index, bool IsError=false, string errorMsg=null} FindStringIndex(string[] strings, string stringToFind)
{

for (int x=0; x<strings.Length; x++)
{
if (strings[x]==stringToFind)
return x;

}

return {-1,true,"String not found"}

}

Usage:

string[] mystrings={"One","Two","Three"};

var val=FindStringIndex(mystrings,"Three");

if (!val.IsError)
Console.Writeline("Found index {0}",val.index);

Alternate usage (works like it doesn't even have those extra parameters but can easilyy access when you need them.:

int! index=FindStringIndex(mystrings,"Three");

if (index==-1)
{
if (index.IsError)
Console.Writeline("Error:",index.errorMsg);

}

The ! like a ? changes the int into sort of a template object, but this one allows access to the named values returned from a method. The first return value is the default but using a default keyword can change that. The default value would be the one default returned.

Alternate usage#2:
string {errormsg} msg=FindStringIndex(mystrings,"Three");

(Not very useful but this using the name of the return value pulls just the value it needs.

Alternate usage#3:
string {string} msg=FindStringIndex(mystrings,"Three");

Retrieves the one string in the return values by type rather than by name.

Personally I don't like this syntax exactly but basically looking for some way to be able to easily return multiple values from a function call without having to create more classes/structs.

I would like to speed up Visual Studio 2015 by disabling the analysis of my sourcecode by Roslyn (code analysis, code fixes, analyzers, etc) when I am working in C# projects. In previous releases of Visual Studio there were two options in the Tools menu >> Options >> Text Editor >> C# >> Advanced:

- Underline errors in the editor
- Show live semantic errors

I am a user of ReSharper, so I do not need this functionality. The reason I think Roslyn is causing the slow-down is that when I use the same version of ReSharper in VS2013, I do not see the slow-downs that I experience in VS2015 (spinning wait cursors, flickering Intellisense menus, etc).

I have seen various suggestions on the Internet, but they do not appear to be the same idea as a nice checkbox would be in the Tools menu >> Options dialog.

Here are the suggestions I have seen to turn off parts of Roslyn:

1) Disable using the "Squiggles" registry key: https://m.reddit.com/r/VisualStudio/comments/42lcal/any_way_to_completely_disable_live_code_analysis/

2) Turning off Analyzers in the active rule set: http://stackoverflow.com/a/31357300/35133

But none of these are "official" Microsoft suggestions, and it would be nice to just be able to eliminate that churn in the IDE period.

Right now, source code integration for framework sources (or any other source-indexed PDB) is clunky. You have to be in a debug session for it to pull down the source.

If you're not in a debug session and use Go To Definition/Ctrl-Click/F12 on a Type/Method/Property, it'll take you to the object browser, or a code view that shows just the signatures.

I propose that VS check for a source PDB in the symbol path first, then if available, use the source code directly. This would be an option, of course, so people can retain the current behavior. It would also presumably cache failed PDB lookups for a period of time to prevent repeated slow lookups. There may also be a way to "force" VS to check for/dl PDBs for the current solution. Bonus: if newer source-enabled PDBs are present, it should replace the existing one.

Overall, this would make it easier to navigate through the source while in the editing context. One could set breakpoints and have them be hit as expected.

Visual Studio has always had options to stop the editor from autoformatting our code. They are found in Options > Text Editor > C# > Formatting > Defaults.

In Visual Studio 2015, you decided to add a bunch of new actions that cause Autoformatting to happen. And you didn't add the option to turn it off to this screen.
Some of the cases where it now happens:
- When I press colon
- When I press {
- Some cases with the using block.

It would be even better to just have a NEVER autoformat my code option - And for the Editor to actually respect it.

If you're writing a tracing and logging component you may well want to pass the current method name to your logging component. Rather than hard code it (then forget to change it when you change the method name) you can use reflection and the MethodBase class to retrieve the name:
System.Reflection.MethodBase currentMethod = System.Reflection.MethodBase.GetCurrentMethod();
System.Diagnostics.Debug.WriteLine(currentMethod.Name);
System.Diagnostics.Debug.WriteLine(currentMethod.DeclaringType.Name);
System.Diagnostics.Debug.WriteLine(currentMethod.DeclaringType.Namespace);

In C # 4.5 you can use attributes System.Runtime.CompilerServices.CallerMemberNameAttribute, System.Runtime.CompilerServices.CallerFilePathAttribute and System.Runtime.CompilerServices.CallerLineNumberAttribute for such purposes.

Frequent use of reflection dramatically reduces performance. Using special attributes is a contentious issue. Because attributes inherently are declarative. They obviously do not provide full support for the aspect programming. Thus, we can conclude that C# developers have created next hack for improving programmability.

At the moment, there is another solution of such a problem. You can use expression trees to improve the code readability. This is a very good approach, especially for refactoring, but it may reduce performance.

class Program {
public static Int32 Counter { get { return _counter; }
set {
if (value < 0) throw new ArgumentNullException(Name.ToString(() => Counter));
_counter = value;
}
}
private static Int32 _counter;
private static void DisplayCounter() { Console.WriteLine("{0}={1}", Name.ToString(() => _counter), _counter); }
static void Main(string[] args) {
Counter = 100;
DisplayCounter();
}
}

using System;
using System.Linq.Expressions;
public static class Name {
public static String ToString(Expression<Action> memberExpression)
{
return _ToString(memberExpression);
}

public static String ToString<T>(Expression<Func<T, Object>> memberExpression)
{
return _ToString(memberExpression);
}

public static String ToString<T>(Expression<Action<T>> memberExpression)
{
return _ToString(memberExpression);
}

public static String ToString(Expression<Func<Object>> memberExpression)
{
return _ToString(memberExpression);
}

private static String _ToString(Expression memberExpression)
{
if (memberExpression == null)
throw new ArgumentNullException("memberExpression");

try
{
var lambda = (LambdaExpression)memberExpression;
var subexpr = lambda.Body;

String name = null;
for (; ; )
{
switch (subexpr.NodeType)
{
case ExpressionType.Call:
name = ((MethodCallExpression)subexpr).Method.Name;
break;

case ExpressionType.Convert:
subexpr = ((UnaryExpression)subexpr).Operand;
continue;

case ExpressionType.MemberAccess:
name = ((MemberExpression)subexpr).Member.Name;
break;

default:
throw new InvalidOperationException();
}
break;
}
return name ?? memberExpression.ToString();
}
catch
{
return memberExpression.ToString();
}
}
}

What if it would be possible to write code that the compiler checked and converted at compile time to a string:

`Counter` => "Counter"
`Program.Counter` => "Program.Counter"
`_counter` => "_counter"
`Counter` => "Counter"
`Display()` => "Display"
`String.Equals` => "String.Equals"
`String.Equals(String, String)` => "String.Equals"

If during compilation process code item mapping failed, the compiler generates an error.

This feature would allow to write faster and better code. Also should mention the opportunities for effective use refactoring. Likewise, the DLR can be extended. It may be safer and more comfortable to use:
PropertyInfo pi = #`Counter`
FieldInfo pi = #`_counter`
MethodInfo mi = #`Display()`
MethodInfo mi = #`String.Equals(String, String)`

This syntax can be ambiguity in the choice between the field and the property, which can be solved as follows:

Assembly asm = #`assembly:System.Reflection`
Type type = #`type:System.String`
PropertyInfo pi = #`property:Counter`
FieldInfo fi = #`field:counter`
MethodInfo mi = #`method:Display()`
MethodInfo mi = #`method:String.Equals(String, String)`

Quite often, it's necessary to validate an object state when it's initialized. With constructor arguments, this is easy to do as it can be done at the end or begining of ctor code. With object initializers, it's nearly impossible, as there's no way to know programatically when the object initialization is finished.

There's a built-in mechamis for this that is being used in WinForms and WPF: the ISupportInitialize interface. The initialization code generated by both toolkits checks to determine if the object implements the interface. If it does, it will call BeginInit() before invoking all property setters, and EndInit() at the end. This provides a nice hook for validating all properties and maybe interrelated ones.

Adding this to the IL generated by the compiler for object initializers would make them inmensely more useful. I'd be willing to replace many ctor overloads with properties if I had that hook, given the much more readable code that results from using object initializers.

The namespace for new files created are automatically determined by the folder structure.
This often creates a problem if you wish to make a logical group of files (by placing them in a folder) that is not supposed to be a new namespace.
Creating the folder and moving the files is not a problem, but the trouble starts as soon as someone uses 'add class' on the folder.
Now the new file does not sit in the same namespace as the other files in the folder.

One example would be to use a folder to store partials of a big class:
[=>Folder root<=]
MyBigClass
[=>MyBigClassPartials<=]
MyBigClass_SetUp
MyBigClass_Update
MyBigClass_OtherStuff

it would be nice if I could assign [=>MyBigClassPartials<=] to the same namespace as the root,
So that new files end up in the correct namespace.

Currently C# disallows constraints for
System.Enum,
System.ValueType,
System.Delegate,
System.Array,
System.Object

However, the CLR has support for classes constrained to All 5 types.
It could be very useful to have this constrain.
To constraint a method to enum we can just use:
where T:struct,Enum
Allowing us to specify only to be called on enum instances and not those boxed as Enum.

Delegate is less strict unfortunately, as there is no way to specify that a T must be an inheritor of a class. A simple solution would be to add an interface to Delegate like `IDelegate` so that we can easily specify only invokable types.

Array is not really necessary as we can make the method have this signature:
MyMethod<T>(T[] array)...

Object is a useless constraint as everything that can be used as a generic argument parameter has to be assignable to system.object.

ValueType isn't necessary as you can use the struct constraint.

Alter section 17.1.3 of the C# language specification to allow for additional language features to be used in attributes. For example, being able to specify a delegate (anonymous or not) would allow one to look up a member-specific validation method using a static method:

public static bool NameValidator(string name) {
return !string.IsNullOrEmpty(name);
}

[StringValidation(NameValidator)]
public string Name { get; set; }

One better would be to allow anonymous delegates or lambda expressions:

[StringValidation(str => !string.IsNullOrEmpty(str))]
public string Name { get; set; }

Better yet would be to allow for generics in attributes:

[Validation<string>(str => !string.IsNullOrEmpty(str))]
public string Name { get; set; }

Readonly modifiers shouldn't be canned for just instance-level properties on a class. Readonly isn't always to explicitly prevent subsequent code from changing a value. I would argue readonly modifiers can significantly improve code comprehension and readability:

Imagine the following code in a method definition, where prod_count would be a local:

int prod_count = (List<Product>) prods.Count;

If the compiler would allow this:
readonly int prod_count = (List<Product>) prods.Count;

All of a sudden, I know as a developer reading the code that I don't have to scan for prod_count getting reassigned to something...I can mentally write it off as, okay that's just the count, I don't have to scroll up or down in the code to see if something is reassigning a value to it.

It would be nice it there were an option to specify if using definitions, added inside a namespace, should be added fully qualified or shortened using the "Quick Fix" command.
Current it's only possible to add shortened usings, which leads to a strange sorting order for sub-namespaces (and doesn't give that good of an overview what namespaces are used in that scope).
Also the current Visual Studio 2015 feature removes the empty line that separates the using definitions and the class documentation comment, that should probably just be fixed.

For details and some screenshots of the current behavior see: https://social.msdn.microsoft.com/Forums/en-US/visualstudiogeneral/thread/8673cc0c-679c-493a-baa3-611a33acdc18/

Karsten