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 @* *@.

WPF should be a superset of WinForms. If not, small enhancements could be made to make this so. This would allow to convert all code from WinForms to WPF with 100% fidelity. This was the huge mistake Microsoft made when they moved to VB.Net from VB6 because they let a 3rd party design the migration, who happened to sell migration services. If they did this right, MS could lower their costs because they would only need to support WPF. This should be a no brainer to help all of the Enterprise developers which are a huge source of the MSDN licenses.

currently, one .NET process shares one GC. making as program gets bigger, cost of GC gets worse and worse and there is no clear way to avoid this problem. most of time, due to this issue, people creates outer proc just to avoid GC cost when doing big analysis or allocation heavy operations. and remote data between these two processes.

please, make better solution and this. explicitly moving data between processes are pain in the ***. this problem basically makes .NET only for small apps. but not for serious apps.

...

one solution I can think of to mitigate this problem is ,instead of this, create a local GC concept, that auto-matically tracks whether a object lives inside of the local GC or references/referenced by objects lives outside of the local GC. and if it references/referenced objects lives outside, promote it to the master GC (the current GC that freeze everyone).

I believe this local GC concept + existing generation GC will reduce time each GC run which ends up making GC cheaper (less object graph to track on each GC) because on top of existing allocation based policy, we now have context.

most of time, when app runs, it runs things in isolation and only small set of objects are actually shared, most of others stays inside of this isolation from the creation to the end.

this is especially true as app going more and more concurrent and immutable.

two features run parallel in different threads sharing GC is a good example since an allocation that should be considered short live now might become gen 1 or gen 2 objects because a features runs in other threads do a lot of allocations.

please, do something to make GC cheaper (how cheaper, please make me never notice GC running when I run very plain, normal big apps such as VS or Roslyn)