"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
}
}
}

It would be nice if the refactor context menu was able to give you an option to refactor a long chain of "if logic" into a strategy pattern:

eg: say these are all descended from a toy class

if(myObj == ball)
{

}
else if (myObj == train)
{
}
else if(myObj == car)
{

}

If you right clicked you'd get an option to refactor to:

ToyStrategies[typeof(myObj)].DoStuff();

It would be very helpful when trying to simplify code rather than having to manually cut and paste edit names etc for each of a very long potential list of possibilities. Doing this kind of stuff has a pretty significant change in the readablity, cyclomatic complexity and extensibility of the code so exposing it as an option would be good.

(Also applies to C++)

I find a very common source of annoying and sometimes difficult bugs is forgetting that integer division truncates the fractional component even when the result is being promoted to a real. As a simplistic example:

int a = 5;
double b = a / 2;

Mathematically one expects b=2.5 but in fact this will result in b=2.0. Of course, one can correct this by instead simply using:

double b = a / 2.0;

However, I wish I had a dollar for every time I forgot to do this.

It would be really nice if this general scenario caused a warning, as the result will probably not be what the programmer intended.

Of course, more complex expressions may result in the promotion not occurring until after the evaluation of one or more other operators, so there would be a bit of work for the compiler, but it should not be too hard. The expression evaluation would just have to propagate a flag indicating whether an r-value relies upon such a division, and when an r-value bearing this flag goes into a promotion to a real, issue the warning.

Thanks for considering this.

Kevin

Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.VisualStudio.OLE.Interop.IServiceProvider'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{6D5140C1-7436-11CE-8034-00AA006009FA}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE)).

{"Unable to cast COM object of type 'System.__ComObject' to interface type 'Microsoft.VisualStudio.OLE.Interop.IServiceProvider'. This operation failed because the QueryInterface call on the COM component for the interface with IID '{6D5140C1-7436-11CE-8034-00AA006009FA}' failed due to the following error: No such interface supported (Exception from HRESULT: 0x80004002 (E_NOINTERFACE))."}

{System.Collections.ListDictionaryInternal}

I don''t know where my last post but this post have detail when I debug them

It probably violates some standard but I find it extremely annoying that I can't nest comments without breaking them. Example:

code line #1
code line #2 /* This is comment #1 */
code line #3

Now I want to comment out all these lines like so:

/* Comment #2
code line #1
code line #2 /* This is comment #1 */
code line #3
*/

The result is that comment #2 is ended by the ending of comment #1, and I get syntax error for the remaining lines.

Is there a reason for this definition of the /* */ syntax?

Of cause, this suggestion applies to all languages supporting "start-end-comment syntax", like C Sharp and Razors @* *@.