Currently, extension methods can only be defined in a static class. It would be very helpful if an extension method could also be defined in an instance class, so that this was possible:

public class Foo
{
public void DoBar()
{
new Qux().GetBaz("corge").DoGrault();
}

private static Baz GetBaz(this IQux qux, string s)
{
// Get Baz from qux here...
}
}

This simply enables a more fluent syntax for private helper methods. This can improve readability of the code compared to a more procedural-looking use of normal static helper methods.

The current workaround is to define a new internal static class, but that opens those helper methods to be used from other classes in the assembly, and sometimes such private helper methods aren't ready for that (they may not properly protect their invariants).

An alternative to the above code would be to allow extension methods to be defined in (private) nested classes.

When we use Linq is very common to check object nullity before access some member

var query =
from t in dc.table
select new {
StringValue = i.Referency1 != null && i.Referency1.Referency2 != null ? i.Referency1.Referency2.StringValue : null,
IntValue = i.Referency1 != null && i.Referency1.Referency2 != null ? (int?)i.Referency1.Referency2.IntValue : null,
};

So.. with a new syntax we can simplify the access:

var query =
from t in dc.table
select new {
StringValue = i.Referency1?.Referency2?.StringValue,
IntValue = i.Referency1?.Referency2?.IntValue,
};

If the object to be acessed is null, the result will be automaticaly null, the result type becomes Nulable<> for value types.
Some other advantages:

someObject?.Close();
Insted of
if (someObject != null) someObject .Close();

myEvent?.Invoke(this, EventArgs.Empty);
Insted of
if (myEvent != null) myEvent(this, EventArgs.Empty);

Thanks

When coding Java in Eclipse, the compiler incrementally compiles the project in the background every time a file is saved. This way, when the user clicks run, the launch is instantaneous, rather than the long build process that comes with C#. This makes it easier to develop and test small changes, which in turn makes it easier to find and fix bugs.

The C# compiler originally had this functionality, but it was removed when .NET 2.0 arrived as it could sometimes cause problems. However, given that it been proved possible in an equivalent language by the Eclipse team, coupled with the obvious advantages a robust implementation of such a feature would bring, makes it an ideal candidate to be reintroduced.

In recent years the C# team has not shied away from difficult and advanced features, so I am confident they could achieve this, and it should provide a big improvement to developer productivity and satisfaction, and make C# more competitive with scripting languages for rapid, iterative development.

Visual Studio only provides hlsl compilation tools for C++ projects, while C# projects which also use hlsl are left without this facility. This is a glaring inconsistency in the tools provided to each language. C# is meant to be a first-class language yet the DirectX tools which are built in to Visual Studio are not equally provided to C#, this is an unnecessary and arbitrary limitation.

Developing DirectX applications with C# is becoming easier and there are now more tools than ever to work with this combination of technologies, including SlimDX and SharpDX, both fully capable managed DirectX frameworks (wrappers). Please provide C# developers with hlsl compilation, and for that matter, all the DirectX and graphics related tools that are provided to C++ developers, including the shader designer and the model editor. These features are equally usable by C#/DirectX developers as for C++/DirectX developers.

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.

If you're a C# developer, I bet you've used something like this before:

***** SomeType DoSomething(params AnotherType[] array){...}

It is a lot easier to use the 'params' modifier than to create a new array with all the paremeters of the same type you want to insert in a method, specially when it comes to small test projects.

However, using this comes with a disadvantage: you MUST use the array type. No IList, List<T>, Dictionary<TKey, TValue>, etc.. I believe there is no such reason not to allow these list-like types to use the params keyword. Example:

***** SomeType DoSomething(params ListType list){...}

Of course you may wonder how is the compiler going to know witch types to accept. Well, for that I have several suggestions: there may be an obligation to derive it from IList<T> or to have at least one indexer... I don't know. What I do know is that this would be a good feature.