What .NET version to choose?

Question

I am writing public .NET class library version for our online REST service and I can't decide which version of .NET to choose.

I would like to use .NET 4.0 version but such compiled class library can't be used in .NET 2.0 version?

Maybe there is statistic how many developers use .Net 2.0 version?

Nihi

In most of these cases I nearly always opt for the lowest version possible, it used to be 2.0 but now I think I can get away with 3.5 so have started building my libraries for that. – Muzzle

What features do you need? The only major complaint I've run into with .Net 2.0 vs newer is users who don't want to download the 3.0/3.5 package due to size. – Tillis

I think it may be bits of the CLR. – Thompson

One of the mantras where i work is never use sunset tech in sunrise products, its a little unique but its definitively an interesting way of looking at things, and to date i don't know of any major issues its caused. – Pre

Why cannot you compile for both 2.0 and 4.0? And forget 3 and 3.5, they're using the 2.0 runtime anyway. – Suntan

@SK-logic: Yes, versions 3.0 and 3.5 use version 2.0 of the CLR, but they also include a bunch of additional features, enhancements, bug fixes, etc. I'm not really sure what your comment means. Why should you "forget them"? – Hartsfield

@Cody Gray, what "bug fixes" are you talking about?!? It is the same runtime. And it is highly unlikely that all that WPF stuff and alike, added in 3.x, would be required by a simple protocol client library. – Suntan

@Suntan What about WCF? 3.5 had some new features and I'm pretty sure it fixed some issues, so maybe Cody Gray means that. – Willem

You really only have two choices .NET Framework 3.5SP1 or .NET Framework 4.0SP1 if you are not using one of those then your making a mistake. There is no reason you cannot supply multiple versions to target different versions of the framework provided you do not use anything that does exist in the previous version. – Ledge

I should add I am just looking at what you should support. If everyone continues to support .NET 2.0 then everyone will continue to support it. We really do not want what happen to Windows XP to happen to older versions of the .NET Framework. I consider Windows XP to be the mother zombie. – Ledge

Answer 1

There's little reason not to use the latest version of the framework. Not only do you get all the latest features and whistles that speed development time, but you also get to take advantage of all the bug fixes and improvements that Microsoft has done under the hood.

The only advantage of targeting earlier versions of the framework is in a vain hope that the user won't have to download and install anything in order to use your app. But that's far from foolproof, and mostly in vain. Remember that Windows is not a .NET Framework delivery channel and you can't reliably assume that the user will have any version of the .NET Framework installed. Even if you insisted on counting on it being bundled with Windows (which you shouldn't), lots of users still haven't upgraded from Windows XP. Even if you counted on it being pushed out over Windows Update, there are significant numbers of users who either don't use Windows Update, don't use Windows Update very often, or who live out in remote areas with poor/slow Internet access and can't download all of those updates.

The moral of the story is that you're going to have to provide the appropriate version of the .NET Framework with your application anyway. And the .NET 4.0 runtime is actually significantly smaller than the previous versions, so there's little reason to target them. The team has worked really hard on that, and their efforts have really paid off. Even better, as atornblad notes, most apps can target the Client Profile version of the framework which trims out some infrequently used pieces and slims things down another ~16%.

Additionally, I strongly recommend using a setup application that handles installing the required framework for the user automatically and seamlessly. Visual Studio comes with built-in support for creating setup applications, or you could use a third-party installer utility like Inno Setup. That makes using the latest version a no-brainer.

Hartsfield

Also, OP could probably compile against the Client Profile of .NET Framework 4, which is really small. – Calenture

Providing the whole .NET framework with a library sounds a bit funny. Any potential library user (i.e., a developer) would unavoidably have a framework and an SDK already, otherwise he won't be interested in a .NET library at all. And yes, there are developers out there who would be angered by a tiny library pushing them into using 4.0 whereas they're bound to 2.0. – Suntan

Don't forget that not all end-users are in situations where they can just download and install any version of .NET they like. Many large corporate environments lock things down heavily. – Terracotta

@Jon: Yes, that's a good reason not to target the .NET Framework at all. You especially can't count on those users having a particular version of the framework installed. – Hartsfield

@SK- You're right, looks like I skimmed the question without reading it carefully enough. For a library it might make sense to provide multiple versions. – Hartsfield

@CodyGray: Not really. There are lots of places which are just a long way behind the curve - and applications may well be developed for those institutions. The place I worked before Google had an uphill job persuading some clients to accept .NET 2.0, but were happy with .NET 1.1. (This was a while ago, but between the .NET 3.5 and .NET 4 releases.) It's really important to remember that the OP isn't talking about building an app, but a class library. (So a setup project doesn't sound useful to me for example.) – Terracotta

@Jon Skeet, I know a couple of relatively big companies in the UK (market leaders in their domains) which are still on 1.1; They've translated from 1.0 just about 4 years ago. – Suntan

Answer 2

Everyone else seems to be recommending using the latest version, so I'll buck the trend and suggest 2.0 if you don't actually need any features from later versions... if this really is a client library and you have no control over and little idea about who is going to use it.

It really does depend on who your users are likely to be, which in turn depends on what the REST service is. If it's some sort of social media thing, then I'd say it's more likely that your clients will be in environments where they can use .NET 4. If it's something which might well be used by financial institutions or other big businesses, they may well not have the option of using .NET 4, so you should consider earlier versions. This is the approach we've taken for Noda Time where we believe the library will be useful in a wide variety of situations, and we can't predict the client requirements.

Of course, if you know all your clients and know they will all be able to use .NET 4, then go with that.

The big downsides of sticking to .NET 2.0 are that you won't be able to use LINQ internally (unless you use LINQBridge or something similar, which adds another dependency for your library) and you won't be able to (cleanly) provide extension methods. If you can usefully expose more features to the client if you use a later version, you may want to provide multiple versions of the library - but obviously that's a maintenance headache.

Another consideration is whether you ought to provide a Silverlight version - which again depends on what sort of service you're providing and what sort of users you're expecting.

Terracotta

It's the same I suggest to him too. If there is a limitation (of any type) in the project OP should choose 2.0 version, to gurantee future development/scallability of app. +1 – Noctilucent

If you provide a .NET 2.0 binary, how do you indicate that it works with 4.0? – Latticed

@Gabe: Do you mean for a full application, or for a class library? There are things you can do in app.config to indicate preferred / required runtimes etc - not sure for a class library. I believe there's generally an assumption that a .NET 2 library will work with .NET 4. That's usually fine, but it has some problems for libraries which include native code. I suspect that's not an issue in this case. – Terracotta

Answer 3

If you are making a REST service you should probably use 4.0.

The only time you need to consider using a legacy version is if another project should reference your compiled dll. The REST service is exposed using HTTP over internet and the client will not use the .dll directly. Or did I understand the question wrong?

Item

OP is obviously talking about a client library. – Suntan

Yes, you understood the question wrong. OP wants to create a client library for wrapping the REST interface. – Calenture

@Suntan I'm here in SO for a while, but sorry for my ignorance, I know "OP" is "one who did the question", but what "OP" stands for exactly? Thank you ;) – Willem

@MatíasFidemraizer - original poster. – Ledge

Answer 4

It's almost always is a good idea to use the latest version, cause MS provides a lot of bugfixes and innovations in those.

If, in your system, there is a limitation for 2.0, I'm afraid you need to use that one, cause you need to "make the stuff work".

For versions approx destribution, can look on this SO answer (but it till 3.5 version)

Noctilucent

"All generalizations are false, including this one". – Ladon

This includes .NET4 – Runnerup

Microsoft keeps releasing bug fixes and security updates to older frameworks. Just this week i got 2 updates for Frameworks 2.0 and 3.5. So, its mostly about losing the new features. – Liz

@Uwe Keim: I invite you to give a concrete answer on this question. The technology choice for a project is a something that goes far away from sites like this. You should be working in the same company, on the same project with the OP in order to give some really useful answer. I just did my best. – Noctilucent

To me, it is almost always a bad idea to use the latest version, since I would lock out tons of customers that download our applications. Being as conservative as possible was always a very good idea. I even downgraded an application once to get more users. – Ladon

@UweKeim: I say it in relation of creation of a new project. If this is in relation of a project maintainance, of a project that has to be integrated into already available subsystem (seems the case of OP) you should choose a version appropriate to your environment. – Noctilucent

Answer 5

When you do not create your library to fit in an existing legacy environment you should always use the most up to date releases.

Yggdrasil

Answer 6

If I don't understand you wrongly you're looking to create a .NET-based client library to work with some REST service(s) made by you too.

Perhaps you want to provide a client library which can be consumed by 2.0, 3.5 and 4.0 applications, and this is absolutely possible, and using best features of each framework version.

Maybe there're more approaches, but I'd like to suggest you three of them:

1. Conditional compilation-based approach. You can implement your classes using a common feature set found in legacy and newer framework versions, but take advantage of useful features present in each version. This is possible using conditional compilation and compilation symbols, since you can define specific code to be compiled depending on target framework version (check this question: Is it possible to conditionally compile to .NET Framework version?).

2. Symbolic links in Visual Studio 2010-based approach. You can choose to use a common feature set, keeping in mind that this is going to be the one found in the oldest version. That is you can create a project which compiles in 2.0, and others for newer versions, adding all compilable files and embedded resources as symbolic links in these Visual Studio projects. This is going to produce an assembly for any of supported framework versions. You can mix conditional compilation-based approach with this one, and you can get a great way of delivering your public assembly in various framework versions in a very reliable and easy-to-maintain way. Note whenever you add a new compiled file or resource to a project, you need to create the corresponding symbolic links for it for your other projects. Check this MSDN article if you want to learn more about linked files: http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx.

3. Version specific, optimized assemblies. Maybe the most time-consuming approach. It requires more effort, but if your REST service isn't a giant one, you can have room to develop an specific assembly for each framework version, and take advantage of best features and approaches of all of them.

---

My opinion

In my opinion, I'd take #2 approach, because it has the best of #1 and #3. If you get used with it, it's easy to maintain and it's all about discipline, and you'll have a good range of choices for your client developers.

Purulence

Answer 7

I'd compromise and use the oldest framework that provides you (the library's author) the most bang for your buck. It's compromise that lets you develop the fastest and exposes your library to the more users. For me, that usually means 3.5 because I tend to use LINQ extensively.

Sidras

Answer 8

It should be trivial to provide both 2.0 and 4.0 binaries, as long as you're not using any of the 4.0 specific dlls.

You can also publish your client library source code - .NET binaries are already so easy to decompile that you're not leaking out anything valuable this way.

Suntan

No, targeting .NET 2.0 in a class library shouldn't cause side-by-side execution. A .NET 4 binary can refer to a .NET 2.0 class library with no issues. – Terracotta