Since more people use Access as an business applications than Visual Studio & other internet programming technologies more business would be generated for server services if those Access application could be exported to Azure services directly with those Azure services supporting any target hardware platforms... Currently it seems the technology diversification (Asp.Net,VB, C#, F#, WPF, Wndows Forms,.......) creates more of an obstacle to the use of services and products.... Focusing on import and export translators (technology independent) for Access would help assure greater use of the server services by mitigating the need for customers to review all the current technologies before focusing on a solution approach...

.NET is starting to have a lot of the same "mess" than Java had when .NET pummeled it in the early part of the last decade. We have stuff like ArrayList, non-generic collections, ADO.NET, stream-based XML processing, and LINQ to SQL all cluttering up the libraries. It's rare I find a .NET developer who things he's using the best tools available but is wasting his time using some of these older, slower, ******-to-use libraries.

.NET is becoming too hard to learn to be good at for new developers fresh out of school. They're going to go to other languages they can find their way around faster. They're also getting taught old and crufty stuff from the old and crufty developers who are comfortable.

At the same time, the last few versions of .NET are moderate evolutionary steps; we need revolutionary before .NET gets pummeled by the competition. Make a grand gesture that .NET vNext is about the future, not the past, and fully remove (not just mark depracated) every feature that doesn't have a serious, truly compelling use case over its alternative in the same library. Yes, it's a breaking change; don't be afraid - it's what's needed. People who haven't updated their .NET app in 10 years will just keep using a previous version, and they'll survive.

Many other teams at Microsoft are starting to demonstrate that the winds are changing for partners who insist on not changing APIs and embracing change. They're making bold statements about the future and rallying the troops around them. Do the same and sweep the messy stuff out of .NET vNext!

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.