Right now, when you are trying to load code in a different AppDomain, you have very few options on how this happens. You call CreateInstance and hope that fusion can find your assemblies (tricky when using a different app base), that the assemblies are loaded in the correct context (you're out of luck when mixing Load and LoadFrom, and who knows what CreateInstance is doing), etc etc.

It would be great if there was a framework type specifically designed to be created in the new AppDomain that you could use to control the process better. Being in the framework, it is always available and will reliably be instantiated. This type could be used to load assemblies in specific load contexts, to handle (better) assembly and type resolution tasks, and for instantiating types for marshalling across the AppDomain boundary in a safe way (e.g., public T CreateProxy<T>() where T:MarshalByRefObject to prevent the common error of unintentional serialization of types).

The recommended usage of SortedList (both generic and non-generic) is to add items in sorted order so items don't have to be moved about in the internal arrays

Currently, the Add method always does an O(log n) binary search to determine where in the arrays the item should be added. It would be better if an explicit check was done before searching to check whether the added item is to be inserted at the end of the arrays (as it would be most of the time, if it's being used correctly), rather than doing a costly binary search to find that out.

This would improve the performance of adding items to SortedList (both generic and non-generic) in the recommended usage pattern from O(log n) to O(1), with negligable performance impact otherwise.

*** Visual Studio 2012 absolutely needs to have an integrated .Net obfuscation feature that works on Windows Store and Windows Phone Store apps & games. ***

The Dotfuscator tool that's integrated into Visual Studio 2012 cannot be used to obfuscate Windows Store or Windows Phone Store apps, making it fairly useless to "modern app" developers who are targeting Windows 8, Windows RT, and/or Windows Phone 8.

On April 30, 2013, PreEmptive (the vendor of Dotfuscator) expired the license of the free (and separately downloadable) "Dotfuscator for Windows Phone 7" tool. PreEmptive now charges $500/year or $150/quarter to use another version of Dotfuscator that will work with Windows Store and Windows Phone Store apps, adding a big expense to obfuscate mobile/modern apps - and that is out of reach for most Indie devs & Student devs.

It is disappointing to see Microsoft's previous deal with PreEmptive (to provide a free version of Dotfuscator for Windows Phone apps & games) come to an end, and without proposing alternative solutions with developer-friendly licensing. Regardless of whether it is PreEmptive's or some other vendor's obfuscator, Microsoft should be helping developers protect their code by providing obfuscation on all Microsoft target operating systems.

At the very least, if this is not economically feasible for Visual Studio Express, developers with Visual Studio Professional (or higher) should expect .Net obfuscation as part of the standard integrated tools.

1. Enhance CLI/CLR metadata for both templates and generics, including variadic.

2. Enhance CLI/CLR metadata for both the partial and full specialization of templates and generics.

3. Enhance CLI/CLR metadata for enhanced expressiveness with regard to template and generic parameter constraints. For example, Expression<Func<Type, bool>>[] GetGenericParameterConstraints().

4. Enhance type, method and extension method resolution and inference heuristics for compile-time, runtime and dynamic language scenarios.

5. Facilitate static interfaces or static interface methods as well as their use in generic parameter constraints and generic method implementations, e.g. T parsed = T.Parse(...).

6. Enhance the structure of builtin datatypes for generic programming.

7. Enhance CLI/CLR metadata for C++ concepts or similar expressiveness.

8. Enhance the C++, C++/CX, C++/CLI and C# programming languages for generic programming, for instance the expressiveness for simultaneous templates or generic types or methods which differ by parameter constraints.

9. Enhance IDL for generic programming.

10. Enhance COM for generic programming efficiently with JIT-optimized .NET programs. Possible is that methods like QueryInterface could exist with either a tree of GUID's parameter, a _Type parameter or another parameter. Additionally possible is that generic methods could receive generics-related parameters (vectors of trees of GUID's, _Type parameters, et cetera) before a this pointer. Additionally possible is that a set of COM interfaces could, as efficiently interoperable with the .NET runtime and JIT, facilitate returning specialized types, method pointers or delegates as per .NET's MakeGenericType() and MakeGenericMethod().

11. Enhance .NET and COM interoperability with regard to generic programming.

Many exceptions in .NET still do not contain any context information which makes it hard to understand when some exceptions happens.

For instance, when a key is already added to a dictionary you throw with the message

"An item with the same key has already been added."

that message does indeed tell what's wrong. But it doesn't aid in bug fixing since we do not know in which context it happened. If you instead added information about the item which failed it would help tremendously.

"An item with the key 'XXXX' has already been added."

What I'm basically asking is that you provide context information which is relevant to why the exception was thrown sit it makes the effort to prevent the exception in the future a lot easier.

Visual C++ should be given way more attention and real developers, who know and understand it, won't be forgetting about C++ for a long long time. VC++ needs to support WPF & WCF, support writing web applications with Visual C++ code-behind and support the Data & DataSource support the VB.NET and C# have thoughout the life-cycle of VS.
Additionally Visual C++ needs InteliSense enabled when working with /CLR not just native based work! Truly, this is atrocious in its current state. C++ should always be kept on the forefront, because it will always be the best, until C# re-writes and mimics everything C++ already could do and will do. Visual Studio/.NET should have the languages in this order, Visual C++, Visual C#, VB.NET / F#.

Make an option that will have the garbage collector (GC) when moving/freeing up memory clears out the memory location with a string of 0s, 1s, or random bits to remove the contents from memory.

Another option would be to have a SecureObject attribute that would tell the GC that this object needs its contents cleared in memory when collecting/moving it.

This would help out with the processing of sensitive information, especially when working with immutable strings.

I do understand that these options would produce a performance hit, but this would not be the default action of the garbage collector and is an opt in functionality.

I find it very useful arraySegment, but I need a class "sister" to extend its usefulness. It allows me to use an array without copying data.

The current Absolute ArraySegment:
it's Aboslute. If Array have 20 items, If offset it's 5 and count it's 10, Still I have to tell you the absolute pointer when working with him.
To indicate the element 7, I have to write Myas(7).

The proposing Relative (new) ArraySegment:
When I point to the 7th element in the array and since the ArraySegment, Offset was 5, I should indicate this Myas (2) not as Myas (7).

To complete this class should also to permit to the property offset to be of reading and writing. Currently, It is defined only when the instance is created.