Skip to content

Future Plans _ Pelase Read

Alfonso J. Ramos edited this page Dec 23, 2015 · 1 revision

With Windows XP long gone from Microsoft's support and a weakening market share, there is little to no excuse to continue supporting .NET 2.0 and .NET 3.0. Even tho, a similar argument can be done for .NET 3.5, it is still in wide use.

Once .NET 2.0 is cutoff from the libraries it will allow for further streamlining by removing code only relevant to maintain this version. This should also make the release binaries for newer .NET frameworks lighter.

Once the base version of .NET for this libraries is .NET 3.5, it may be convenient to remove Tasks from the libraries, as users willing to take advantage of Tasks can use Microsoft TPL and Async Bridge both available as NuGet by OmerMor.

Another advantage of having .NET 3.5 as base version, is that System.Core and WindowsBase will not need to be optional references, which will improve IDE support. In fact, without the need to backport WindowsBase to .NET 2.0, it may be possible to remove it altogether. This also paves the way for introducing current FAT features as a separate assembly.


I find it weird to remove compatibility to old version in project intended for backporting. OF course these are breaking changes and should be numbered accordingly.

At the moment of writing promise style tasks need more work, and waiting multiple tasks simultaneously is not currently possible. The old plan was to complete TPL backport to .NET 2.0 and include a port Async Bridge to allow the use of the async keyword in .NET 2.0. And this - I am sure - is doable.

Although it may be not worth it. Or is it? I Need to know if people still want to use this libraries to run code on .NET 2.0, these libraries has been cheered for the inclusion of LINQ Expressions in various occasions, yet this is just an small niche... I have to promote these libraries or it may also be that there is really no more interest in something them.


I'm interested in waiting for Xamarin Studio to improve C# 6 support to go thru old parts of the code. The required improvements should hit stable release in January or February of the next year. Since I'm planning the above changes, this could be done simultaneously.