The Tools / Options dialog contains the following settings for running the application:

On Run, when build or deployment errors occur:
"Launch old version", "Do not launch", "Prompt to launch".

If I hit Ctrl-R A to run all tests and the build results in errors, then the following dialog appears:

"There were build errors. Would you like to continue and run tests from the last successful build?"

This is a hassle, in particular when implementing in TDD-style.
It would be very convenient to have the same choice for tests as for application launch:

On Test, when build or deployment errors occur:
"Launch test from the last successful build", "Do not test", "Prompt to test".

Please make it easier to find related work items from the new pending changes view. I would like to see a search box instead of a text box to enter a difficult to remember unique ID. If I absolutely must drag & drop work items to this canvas, then I would like an easier way to open up a work item query without having to navigate away from the pending changes view. I'm surprised this wasn't addressed in the Beta as I can't imagine anyone actually who has used this preferring it to the old way of associating work items with pending changes.

"Find and Replace" should exit when the user hits Escape. F&R should never steal input focus. If it is visible but without focus (eg focus is source code editor), a run and quit results in F&R with input focus at the "Find what" text box. If F&R has focus but NOT in "Find what" text box, run and quit results in focus moving to "Find what". I think F&R is behaving less like a developer's tool and more like the boss. I would be satisfied if it exited on the Escape key (aka Cancel, like things should work). I think now the only way to close it is with the mouse, and that violates GUI guidelines.

Just like Nullable<int> can be written as int? I would like to be able to write int* in stead of IEnumerable<int>. This would of course also work for reference types like a custom defined Person class. IEnumerable<Person> would then be equivalent to Person*.

IEnumerable<T> has become a very important type within the .NET framework and in my opinion it would make sense to include some minor syntax in the C# language to avoid to have to write the types rather long name for example when defining method parameters and return values that are enumerable. The 'var' keyword isn't allowed everywhere type names are.

I am using CS for new projects due to its increasing popularity. However, I can't help but compare the better coding experience I have in VB.Net over CS.Net.

I am noting several points that may serve as your basis for improving the transition of developers moving from VB to CS, to improve the CS IDE.

1.) I find typing the using statements on top of my classes an unnecessary repetitive tasks. In VB.Net, you have the project property pages where you can specify a global Imports statements.

2.) I also observe that when I create classes, the class is placed in a namespace which includes the name of folders of the class file. This may be a useful technique based on your study and evaluation, but why is this implemented differently in VB where the default namespace is the project namespace? I find merits in both techniques but I think that there should only be a single implementation of this namespace thing in both languages in the IDE.

3.) I am annoyed by the lack of typing support in ending statements with a ";" Why shouldn't the editor "intelligently" end statements with the semi-colon whenever it is needed? In VB, I think the editor ends statements with a linefeed automatically.

4.) Same with the ending "}". Why shouldn't the editor end opening braces with closing braces? In VB, when you start statements - i.e. Sub, Function, If, Class, Interface, etc. - it automatically types in the necessary "End _______" statement

5.) Anothing important thing I notice is that the "background" compilation is slower in C# than in VB.

Of course, there are things I am starting to like about CS (like the "better syntax" of casting types).

I am just starting out, I may, or need to, get the hang of writing in CS because of its increasing popularity, but I think you guys need to improve CS in terms of the "coding experience" as this has a great impact on the productivity of developers.

// Say I want to encapsulate a field, event, property or method, so that is only visible to parts of its class -
// Common use cases include:
// - lock objects, fields shared by multiple threads, to which access should be tighly controlled.
// - restricting access to an event to a few helper methods
// - partial class scenarios

class Problem
{
private int someValue; // this value should only be accessible by ScopedMethod() and related wrapper methods

protected int ScopedMethod()
{
return someValue++;
}
}

// The only way to do that right now is to declare a nested class and stuff the private field in it.
// In the static case:
class StaticField
{
protected static class MyScope
{
private static int someValue; // this field is now only visible within the scope of the nested class.

public static int ScopedMethod()
{
return someValue++;
}
}
}

class DerivedStaticField : StaticField
{
void UseScopedMethod()
{
Console.WriteLine(MyScope.ScopedMethod()); // note the need to qualify the method call...
}
}

// the same is true for instance fields. Note the verbosity and the need for an extra field and allocation

interface IScope
{
int ScopedMethod();
}
//
class InstanceFields
{
protected readonly IScope MyScope = new Scope();

private class Scope : IScope
{
private int _someValue; // this field is now only visible within the scope of the nested class.

int IScope.ScopedMethod()
{
return _someValue++;
}
}
}

class Derived : InstanceFields
{
public void UseScope()
{
Console.WriteLine( MyScope.ScopedMethod() ); // again, any call to the scoped method needs to be prepended with MyScope
}
}

// In addition, non-static fields are not accessible from within the nested class.
// One must pass the parent in the constructor of the nested class:

class Parent
{
private object field = new object();

protected Scope MyScope;

Parent()
{
MyScope = new Scope(this);
}

protected class Scope
{
private Parent _parent;
private int _someValue; // this field is only visible within the nested class.

public Scope(Parent parent)
{
_parent = parent;
}

void UseParentField()
{
Console.WriteLine(_parent.field);
// does not compile: Console.WriteLine(field);
}
}

}

// WISH: a better solution would be to introduce a new "scope" keyword
class MyClass
{
scope MyScope
{
private int _scopePrivateField; // this field is only visible within the scope.

public int ScopedMethod()
{
return _scopePrivateField++;
}
}
void Use()
{
ScopedMethod();
// but scopePrivateField is not accessible
}
}
// - there may be multiple scopes in a given class (or struct).
// - the class boundary would be an implicit scope (as usual)
// - private, protected or public fields in the parent scope or class would be accessible from the nested scope
class MyClass2
{
private int _classPrivateField;

scope MyScope
{
int SomeMethod()
{
_classPrivateField++;
}
}
}

// instance fields in a scope would belong to / be tied to the class instance, just like instance fields in a class
class MyClass
{
public scope MyScope
{
public int Prop { get; set;}
}
}

class Container
{
private MyClass myClass = new MyClass();
myClass.Prop++;
}

// scopes could be private, protected, internal, protected internal or public like nested classes
// with the same implicit access level

class MyClass3
{
private scope Private
{
private int privateToScope;
public int accessibleFromClass;
// protected makes no sense here
}
protected scope Protected
{
private int privateToScope;
public int accessibleFromClassAndDerivedClass;
}
internal scope Internal
{
private int privateToScope;
public int accessibleFromClassAndAssembly;
}
public scope Public
{
private int privateToScope;
internal accessibleFromClassAndAssembly;
public int accessibleFromEverywhere;
}
}

// effect of scopes in derived classes:
class Derived3 : MyClass3
{
void Use()
{
// Private scope not accessible
// Protected scope
accessibleFromClassAndDerivedClass = 1;
// Public scope
accessibleFromEverywhere = 1;
}

}

// another example with events
class EventExample
{
protected scope MyScope
{
private EventHandler SomeEvent;

public void OnSomeEvent() // events are usually fired from a helper method, because of the need for a null check...
{
if (SomeEvent != null)
SomeEvent(this, new EventArgs());
}
}

private int _someValue;

public int SomeValue
{
get
{
return _someValue;
}
set
{
_someValue = value;
OnSomeEvent(); // SomeEvent is not accessible outside of the scope
}
}
}