Is it possible to target the .NET 3.5 framework?

[aaronlerch]

If there is a better or different forum for asking a question like this, please let me know, it wasn't immediately obvious to me where to ask.

I compiled a version of clrzmq targeting the 3.5 framework version, to see how much of 4.0 the library is using. It turns out, not very much. Most notably there is the ConcurrentDictionary usage (1 location) and a few other easily implemented items, such as System.Lazy and String.IsNullOrEmpty, to name a few. There is a SpinWait class used once, however that appears to be an optimization that might have other workarounds or worst-case could use a sleep (I didn't analyze the code around it to be sure.)

Overall I found there to be nothing immediately or obviously compelling about using .NET 4, and wondered what the impact and possibility would be of changing the target to be 3.5. This would open a whole host of usage scenarios for apps that aren't able to be 4.0 yet, for one reason or another.

My particular use-case is that I'm writing extensions for a deployed application that targets the 3.5 framework (running on the 2.0 runtime), which means .NET 3.5 is my maximum usable framework version. I would like to use clrzmq but currently can't, at least not the 3.0 version.

Thanks! Aaron

[aaronlerch]

And yes, I hate to be "that guy" asking this, but in my experience, it never hurts to ask! :wink:

[jgoz]

Well, you wouldn't be the first "that guy" to ask for this (see #59) :smiley:

My response is basically the same here. 4.0 was released more than 2 years ago and, as of last month, 4.5 has also been released. I would consider code targeting the 2.0 framework to be legacy code and I would rather not spend the time rewriting parts of the beta branch to support it. In particular, the usage of SpinWait would be hard/error-prone to replicate; it provides a reduction from 99% to <5% CPU usage in certain situations, so I'm not too eager to remove it.

I think your best bet would be to use the 2.2 stable release because it targets 3.5 and will continue to be supported & maintained until libzmq 2.x is officially retired.

If you were really keen, however, you could fork clrzmq and port the master branch to target 3.5 — I'm sure there would be more than a few people interested in that. And if you find a way to keep CPU usage low in the cases where SpinWait is being used (basically, during Receive calls with timeouts), I would be willing to accept a pull request. But I'd need some extra evidence that the performance characteristics have been kept the same (or improved... :smiley:).

I hope that's a sufficient answer. I'm going to close this issue for now.

[aaronlerch]

That's perfect, thanks. :) I'll work with 2.2 for now as I'm not excited about maintaining a fork, especially when the moment comes that you begin to leverage more of .NET 4 or 4.5. :smile:

If push comes to shove, I will create a fork.

Thanks!

[jgoz]

I'm not excited about maintaining a fork

Totally understandable. Thank you for the feedback.

[Super-Genius]

Not to open an old wound, but it would be nice to have 3.5 for the sake of using the framework in Unity3d.

The NetMQ system has it's own way of doing things and isn't even interoperable with respect to "ipc" sockets, otherwise I would use that system.