Should I rely on future developments in .NET related to asynchronous programming?

Question

I have just started working on a reusable library. This library is going to be pretty big and since it involves communicating with external devices over various communication media (such as RS232, TCP/IP, Radio etc), I am thinking about providing support of performing operations that involves communication, asynchronously.

I have read the .NET guidelines, various articles etc. Many sources refer to future developments in .NET 4.0 regarding asynchronous programming.

I have 2 options:

1. Forget .NET 4.0 and implement the library using best pattern/method available today.
2. Read, learn and play with .NET 4.0 so that my library gets benefit of up-to-date language and framework facilities.

Considering that release timeline of my library goes till mid next year (2010) and quality of library matters more than release date (Yes, I am lucky), what option would you recommend?

If you suggest option-1, is there anything I can do to make my library ".NET 4.0 friendly" (easy changes in future to use advanced parallel features)?

If you suggest option-2, how stable the current parallel features in .NET 4.0 or how much rework you expect because of working on beta platform?

Answer 1

Regarding your first point, all 3.5 or even 2.0 assemblies can be used from .NET 4.0. As of 2.0, .NET is fully backwards compatible (till 2.0 anyway).

Answer 2

You say that your library is due to be released next year - do you know what version your customers are likely to be running? .NET 4.0 will still be quite new at that point. If your customers aren't willing to run it, that rules it out.

If you can use .NET 4.0, I'd say that the PFX bits are likely to lead to much cleaner code. It's really nice. Things are still changing though... I know that there will be some changes between beta 1 and beta 2. My guess is that beta 2 will be a lot closer to the final bits though.

EDIT: Okay, so if you can use .NET 4.0, I would do so. I have a lot of faith in the PFX team, and it's a very nicely designed library. One difficulty is that while there are loads of blog posts and some documentation, there aren't "real world applications" books yet - and you'll find that some of the blog posts will be slightly out of date already. I suggest you start with the PFX team blog as well as the documentation in beta 1. Just be aware that things will change...

Answer 3

I would clearly go with option 1 - write your library using the idioms that work now.

As for making future transitions easy, make sure you design the public interfaces well. Use the same principles as always, i.e. keep them clean and don't expose internal implementation details.