in. net 4 can compile code at runtime and loading it into the AppDomain. It seems to me that you want to extend this useful functionality and allow execution of arbitrary code from the right during the execution of the program, and in the same namespace, or in the same AppDomain, and have access to all connected to the library project. For example I need to calculate the data according to the formula, but formula can vary depending on the legislation, or other causes. And it would be nice to be able to execute code from a string. Then they would adapt the program was simple and straightforward. This kind of scripting language itself.
Thank you!

When i tested GC performance (C# "new" allocation speed of arrays and objects) of .NET 4.0 i found at least 1 huge perforamnce issues.

To significantly improve C# allocation speed and whole .NET programm performance, especially in games, i suggest to make the following:

1) DO NOT "ZERO" memory synchronously before allocation (like .NET 4.0 does). Next-Gen is to Zero memory ASYNCRONOUSLY (in other thread) and right AFTER old object release, NOT before new allocation. This will BOOST memory allocation speed to the heavens. In short words all memory must be zeroed beforehand.

2) [less important for now] Make private memory allocation pool PER every processor Core, so lock (synchronize) memory allocations only inside Core. This will make better allocations speed scalability for multi CORE/processors.

This 2 improvements will make memory allocations no longer "time critical", this will be new age of memory allocations with FREE cost, no longer need for everywhere precashing and so on. With this imrovements, when you need memory allocation, just allocate it! without any time cost: for syncronization, zeroing or searching for free block. This will be the TOP of memory allocation performance, new age of memory (objects) allocations with really free time penalty.

(Of course with combination of devidable by 2 memory blocks allocations, for O(1) fast free block searches. Something like in Unreal Engine Fast Windows Allocator, i think this is already implemented in current GC, at least i hope i am right, because current GC allocation not so slow like C++ allocation).

PS: often you dont need entire allocated buffer or array filled or zeroed, often "big enaugh" allocated buffers even not used at all, or used just 10% or even less, and only after 1 hour of work. In this situations current "blocking zeroing after initialization" is disastrous. Or if you allocate small objects "very" "very" "very" often - its also disastrous, just because of many objects will not use their allocated buffers entirely, or even at all (for example many arrays with Capacity). So "asynchronous zeroing after garbage collect" in combination with reusable GC large preallocated blocks - will fix all this issues for many avarage size objects and arrays (0-65000 bytes for example). Yes this may increase memory usage is some way, but not much, and this is very good price for performance.

This initially appears to be a high-level object, but blocks access to high-level HttpWebRequest properties like CookieContainer, IfModifiedSince, AllowAutoRedirect, UserAgent, Referer, ContentType and Encoding; and high-level HttpWebResponse properties like LastModified, ContentType and Encoding. Instead, you have to add or retrieve these headers as strings, manually providing or consuming any dates in the obscure HTTP header format, and parsing the Encoding from the Content-Type.

Without cookies, WebClient isn't well-suited to most tasks requiring multiple requests. Without the other headers mentioned, it is also not well-suited to nontrivial requests.

WebClient also doesn't provide static methods for simple requests, but instead requires management of an instance object, so it isn't really optimized for trivial requests either.

The current WebClient is a naive implementation, suitable primarily for subclassing a useful implementation.

I hereby propose a WebSockets library for the .NET framework, which must be included in all future releases of the .NET from version 4.0 upwards.

A library providing native support for WebSockets, both server and client applications, must be considered an essential requirement for the next major version of the .NET framework.

WebSockets provide functionality that is absolutely integral to the future of web applications. The latest version of every major web browser supports WebSockets. Every major browser vendor is adopting the WebSockets API along with the HTML5 specification.

This type of architecture is already extremely popular and widely used, especially in applications targetting specific clients e.g. on mobile devices. WebSockets usage is growing fast.

Yet, currently, implementing WebSockets using .NET, like other development platforms, requires a huge amount of code just to provide basic functionality. The vast majority of this could and should be provided by the framework, leaving developers to focus on useful functionality, which is of course the purpose of a framework.

The problem is abundantly clear in any .NET implementation of a WebSockets server, e.g. SuperSockets. It takes hundreds of lines of code just to get started with laying the foundation sof any WebSockets functionality -- and sadly the same is true in any programming language.

I therefore strongly urge Microsoft to begin working on a WebSockets assembly for .NET without delay, or if one is not already in the pipeline to expedite this with the maximum possible haste!

Blogged, along with further information and evidence to support the case:

http://www.timacheson.com/Blog/2011/nov/microsoft_websockets

There are many programmers and company that develop applications based on geometrical kernels that use OpenGL for drawing (like CAD/CAM applications) often they have an old MFC application, and to pass to a modern view for their applications and give a new user experience for the user they could make new WPF interfaces very quickly but they can't rewrite an entire kernel to pass from OpenGL to DirectX, so often they prefer to remain with MFC without pass to WPF. This could be a very special thing to have the possibility to use OpenGL fully supported by WPF, without airspace iusse.
Now it's possible the integration using HwndHost or WindowsFormsHost but it's not possible to have other WPF control over this, and it's impossible to apply effects and transitions.

As it stands, the ConcurrentDictionary has a GetOrAdd method that accepts a valueFactory delegate that is not included within the scope of the lock, hence it can be executed multiple times and as a result adding the value to the dictionary and executing the valueFactory is not an atomic operation. This behaviour seems to be misleading in relation to what the API leads one would assume that the benifit of having a method accepting a function overload would be. Let's see an example:

For example, the intention of the following code is clear:
Object value = ValueFactory(); myConcurrentDictionary.GetOrAdd(key, value)

From the overload that accepts only the value it is crystal clear that when I invoke the valueFactory, it is not thread safe.

Now suppose we have

private string ValueFactory()
{
// some logic for creating a value
}

myConcurrentDictionary.GetOrAdd(key, ValueFactory)

The developer is left thinking, "now what could the added value of this overload be!?" - and then comes the false assumption "aha, the cool guys developing the concurrent dictionary thought that I might need to enlist some additional actions within the lock for adding as an atomic operation, great!" Of course, this is not the case. So as a result there appears to be little added value of having this method overload provided by the platform, given that I can already invoke my value factory in an unsafe way.

Understandably, when the team desiged this feature in this way, we can assume it was decided to 'protect' the developer by avoiding the risk of locks acquired during a long period of time due to slow running valueFactories. But why add this overload then, if I already have a way of invoking valueFactory in a thread unsafe way that is more explicit?

To address this issue, In the future, I would really like to see an overload with an option of lockBehaviour for the valueFactory (if it should be included or excluded from the lock) - By adding such a switch, it will allow for backwards compatibility (with a default of e.g. ValueFactoryLockBehaviour.ExcludeFromLock) and it would also empower the developer to choose if he wants to have valueFactories execute as atomic operations with the add and at the process allow for shooting himself in the foot by potentially acquiring a looooong running lock. (After all with great power comes responsibility)

A couple of links:
[1] http://ayende.com/blog/4802/concurrentdictionary-getoradd-may-call-the-valuefactory-method-more-than-once
[2] http://geekswithblogs.net/BlackRabbitCoder/archive/2011/02/17/c.net-little-wonders-the-concurrentdictionary.aspx

It is great that code coverage analysis can be easily run from test explorer window in VS 2012. But I suppose that it is often not appropriate to analyze code in test assembly itself. I think that it well be appropriate to exclude test assemblies from code coverage totally by using ExcludeFromCodeCoverageAttribute on assembly level in those assemblies so they will not produce 'garbage' code coverage results.

Now it is not possible since ExcludeFromCodeCoverageAttribute cannot be used at assembly level. There are several possible targets for this attribute however, allowing for some flexibility. I think, it will be convenient to allow assembly level as well (with corresponding support from code coverage analyzer).