Which version of .NET to choose?

I am writing a public version of the .NET class library for our online REST service, and I cannot decide which version of .NET to choose.

I would like to use .NET 4.0, but such a compiled class library cannot be used in .NET 2.0?

Perhaps there are statistics, how many developers are using .Net 2.0?

+7
source share
8 answers

There are few reasons not to use the latest version of the framework. Not only do you get all the latest features and whistles that speed up development time, but you can also take advantage of all the corrections and improvements made by Microsoft under the hood.

The only advantage of targeting early versions of the framework is the vain hope that the user will not have to download and install anything in order to use your application. But this is far from flawless, and mostly in vain. Remember that Windows is not a .NET Framework delivery channel , and you cannot reliably assume that a user will have any version of the .NET Framework. Even if you insisted on relying on it being connected to Windows (which you shouldn't), many users are still not updated with Windows XP. Even if you think that it is pushed out of Windows Update, there are a significant number of users who either do not use Windows Update, do not often use Windows Update, or live in remote areas with low / slow Internet access and cannot download everything these updates.

The moral of this story is that you still have to provide the appropriate version of the .NET Framework in your application. And the .NET 4.0 runtime is actually much smaller than previous versions, so there is no reason to configure them. The team has worked very hard on this , and their efforts really paid off. Even better, as atornblad notes, most applications can focus on the client profile version within a framework that cuts off some rarely used fragments and reduces the number of things by another ~ 16%.

In addition, I highly recommend using a configuration application that automatically and easily processes the necessary infrastructure for the user. Visual Studio comes with built-in support for creating installation applications, or you can use a third-party installation program, such as Inno Setup . This makes using the latest version no problem.

+8
source

Everyone else seems to recommend using the latest version, so I will support the trend and suggest 2.0 if you do not need any functions from later versions ... if it is really a client library and you have no control and little idea who is going to use it.

It really depends on who your users will be, which in turn depends on what the REST service is. If this is something like social media, then I would say that your customers will be in an environment where they can use .NET 4. If this is something that can be used by financial institutions or other large companies, they can be with you there is no way to use .NET 4, so you should consider earlier versions. This is the approach that we used for Noda Time , where we believe that the library will be useful in a variety of situations, and we cannot predict customer requirements.

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

The big disadvantages of using .NET 2.0 are that you cannot use LINQ internally (unless you use LINQBridge or something similar, which adds another dependency for your library), and you cannot (purely) provide extension methods. If you can usefully provide additional functions to the client, if you use a later version, you can provide several versions of the library, but obviously, the headache of the service.

Another consideration is whether to provide a version of Silverlight, which again depends on what service you provide and which users you expect.

+4
source

If you are creating a REST service, you should probably use 4.0.

The only time you need to use the legacy version is if another project has to reference your compiled dll. The REST service opens over HTTP over the Internet, and the client will not use the DLL. Or did I misunderstand the question?

+2
source

It is almost always useful to use the latest version, because MS provides many fixes and innovations in them.

If your system has a 2.0 limit, I'm afraid you need to use this because you need to โ€œget the job to work.โ€

For distribution-related versions, you can see this SO answer (but before version 3.5)

+1
source

If you do not create your library in accordance with the existing obsolete environment, you should always use the latest versions.

+1
source

If I do not understand you correctly, you want to create a .NET-based client library to work with some of the REST services you created.

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

There may be more approaches, but I would like to offer you three of them:

  • Conditional approach based on compilation . You can implement your classes using the common set of functions found in versions of obsolete and new versions, but take advantage of the useful functions present in each version. This is possible using conditional compilation and compilation symbols, since you can determine the specific code to compile depending on the version of the target structure (check this question: Is it possible to conditionally compile a version of the .NET Framework? ).

  • Symbolic links in an approach based on Visual Studio 2010 . You can use a common set of functions, keeping in mind that this will be the one found in the oldest version. That is, you can create a project that compiles in version 2.0 and others for newer versions, adding all the compiled files and embedded resources as symbolic links in these Visual Studio projects. This will create an assembly for any supported version of the framework. You can combine the conditional compilation approach with this, and you can get a great way to deliver your public assembly in various versions of the framework in a very reliable and easy to maintain way. Please note, when you add a new compiled file or resource to the project, you need to create the appropriate symbolic links for it for your other projects. Check out this MSDN article if you want to know more about related files: http://msdn.microsoft.com/en-us/library/9f4t9t92.aspx .

  • Version, optimized builds . Perhaps the most time-consuming approach. It takes a lot of effort, but if your REST service is not gigantic, you may have a place to develop a specific assembly for each version of the framework and use the best features and approaches of all of them.


My opinion

In my opinion, I would take approach No. 2, because it has the best of # 1 and # 3. If you get used to it, itโ€™s easy to keep it all about discipline, and you will have a wide choice for your developers.

+1
source

It should be trivial to provide both binary 2.0 and 4.0 if you are not using any of the 4.0 specific DLLs.

You can also publish the source code of your client library - .NET binaries are already decompiling so easily that you wonโ€™t miss out on anything of value in this way.

0
source

I would jeopardize and use the oldest framework, which provides you (the author of the library) with the strongest blow for your dollar. This is a compromise that allows you to develop the fastest and provides your library with more users. For me, this usually means 3.5, because I often use LINQ.

0
source

All Articles