3.5 compatibility: second proposal

[luna-duclos]

As I don't like the way the first 3.5 pull request handles the problem, here's my own proposal on how to handle 3.5/4.5

• I've changed the .NET version for the main NetMQ project to 3.5 and made some changes to not use .NET 4 only classes, I've done my best to keep those to a minimum
• I've added a NetMQ.Net45 project that contains all code specific to .NET 4.5, currently, this is only the Scheduler
• I've added a NetMQ.Net35 project that links to the Net45 one, but uses .NET 3.5 and a downgraded version of the TPL from nuget to be able to support the Net45 only features.

This has a few advantages over the other approach:

• No version checking needed in precompiler statements
• Ability to mix Net35 & Net45 projects within the same solution and have everything compile properly (this is the killer for me, I very much wanted this)

[tobi-tobsen]

@somdoron I like this approach better than the other one. What do you think?

[somdoron]

@tobi-tobsen I actually liked the other one better but I can go with both, however both pull requests cannot be merged automatically, so somebody need to resend one of the pull requests.

[JamesWHurst]

Sorry for my hiatus - I've been travelling for work and have not had my main cptr with me.
I submitted a pull request which would have provided full .NET 3.5 compatibility, last year. I don't see that it got merged-in. Now, I see the same work of our other contributors (above), which sounds good to me. Where do we stand right now on this - do one of us need to do some manual merging? Mine is now a year out-of-date, so that might be a bit of a chore, but I'm willing to do it.
I do, sort of, like the idea of using distinct projects to encompass 3.5 and 4.0/4.5 compatibility, but something to consider is that there are numerous places within the code that benefits from post-3.5 code, and in fact the API can benefit slightly from post-3.5 enhancements such as default param values. Slightly. I submit that with more than two .NET versions, each of which provides useful code features, that using precompiler pragmas might be considered worthwhile, as long as those are well-documented (ie, I list those at the top of every module in which they're used) and not extensive. It can help, sometimes, to see the modern code technique, alongside the older code technique, and visually see how they compare, but again only if they are not extensive. That's my thoughts - I am not firmly married to this path and can happily go either way. My pull-request did include extensive additional Intellisense-compliant comments for some of the API, which has been sadly lacking. In fact I see that as my main contribution. So, please, let me know your thoughts and, hopefully, we can get a solid 3.5-compatibility fix in. If not already. Thx gentlemen.

[somdoron]

As master now supports dotnet3.5 i'm closing the pull request