To create in the newest .NET framework or the least necessary version?

BrokenArrows

Having a discussion today with some people at work.

Im of the opinion that unless you need a feature of say 3.5 or 4 you should build using the least necessary version eg. 2.0 or possibly even 1.1 if its a very basic program.

Where as some people in the office build using 3.5 or 4 for no reason other than its the latest version but they may not necessarly use any of the features specific to that version.

The way i see if having a prereq of 2.0 most people are likely to have it already installed while 3.5 or 4 are not as widely installed!

Or should i be forcing myself to use the latest features of .NET?

What do you think?

srsly78

Err the early versions were ****e. It only started getting good after 3.5 :pac:

The only reason to target a lower version is if you care about mono compatibility.

Everyone will have 3.5 or 4 installed, and if not then your installer will rectify that pretty sharpish. Not a big deal.

Colonel Panic

srsly78 wrote: »

Err the early versions were ****e. It only started getting good after 3.5 :pac:

The only reason to target a lower version is if you care about mono compatibility.

Everyone will have 3.5 or 4 installed, and if not then your installer will rectify that pretty sharpish. Not a big deal.

Files.zip?

philologos

It depends on who or what you are building for. In my work, we only produce software that will be used within the business. The computers all get a build with certain software (inc .NET 4.0), and there is an automated deployment system in the event that certain prerequisites aren't installed on the machine. We for the most part use .NET 4.0 and if necessary 3.5.

There are a lot of handy things in .NET 4.0 such as dynamic objects.

BrokenArrows

philologos wrote: »

It depends on who or what you are building for. In my work, we only produce software that will be used within the business. The computers all get a build with certain software (inc .NET 4.0), and there is an automated deployment system in the event that certain prerequisites aren't installed on the machine. We for the most part use .NET 4.0 and if necessary 3.5.

There are a lot of handy things in .NET 4.0 such as dynamic objects.

The intended destinations of the software are guaranteed to have 1.1 and 2.0 hence my choice.

They might have 3.5 or 4 but not guaranteed.

srsly78

There are deployment tools that will make an installer for you, simple stuff.

http://www.youtube.com/watch?v=Lcue0jo41AM

This is a general thing, all non-trivial software comes with dependencies. Dlls need to be registered and so on.

philologos

BrokenArrows wrote: »

The intended destinations of the software are guaranteed to have 1.1 and 2.0 hence my choice.

They might have 3.5 or 4 but not guaranteed.

As others have said, if you create a setup project in the solution with your software, if the user doesn't have the .NET Framework as a prerequisite it will install it onto their system before use.

For the record, 1.1 and 2.0 I wouldn't recommend at all. You're missing out on key and useful technology at that point. (Do you really want to keep your application in WinForm rather than WPF for example?). Do you really want to use ASMX webservices rather than WCF for SOAP bindings and so on? Do you want to limit the assemblies that you can reference in your project? (Most will be 3.5 at least).

There are a lot of questions you need to ask if you're going back to that point.

It's important to note that Windows 7 includes the .NET Framework 3.5 by default, and I anticipate .NET 4.5 will be included on Windows 8 when it's released in October. (One of the nice features of that will be async methods)

BrokenArrows

philologos wrote: »

BrokenArrows wrote: »

The intended destinations of the software are guaranteed to have 1.1 and 2.0 hence my choice.

They might have 3.5 or 4 but not guaranteed.

As others have said, if you create a setup project in the solution with your software, if the user doesn't have the .NET Framework as a prerequisite it will install it onto their system before use.

For the record, 1.1 and 2.0 I wouldn't recommend at all. You're missing out on key and useful technology at that point. (Do you really want to keep your application in WinForm rather than WPF for example?). Do you really want to use ASMX webservices rather than WCF for SOAP bindings and so on? Do you want to limit the assemblies that you can reference in your project? (Most will be 3.5 at least).

There are a lot of questions you need to ask if you're going back to that point.

It's important to note that Windows 7 includes the .NET Framework 3.5 by default, and I anticipate .NET 4.5 will be included on Windows 8 when it's released in October. (One of the nice features of that will be async methods)

I guess its time to stop using 2.0 then.

philologos

srsly78 wrote: »

There are deployment tools that will make an installer for you, simple stuff.

http://www.youtube.com/watch?v=Lcue0jo41AM

This is a general thing, all non-trivial software comes with dependencies. Dlls need to be registered and so on.

DLL's don't have to be registered. Sure you can register them in the GAC if you want, but you can also just simply reference them and copy them in place with your solution. A bit of clever editing of project files and the solution file can help in compiling as well. It depends on the type of dependency I guess, and the level. For example 1st level dependencies, or 2nd + level dependencies.

srsly78

It gets more complicated when you mix in native dlls (COM stuff), and have to support both 32 and 64bit. And no, selecting "mixed platforms" does not work Even VS doesn't support this properly, you have to edit the proj files by hand -.-

Colonel Panic

One of the most tedious things I've ever done, but also the most worthwhile, was learning how to make installers with WIX. Does dependencies, will set up firewall rules, start services and you can bootstrap other MSIs like the .Net framework.

Sending a client some files and hoping it will all work is amateur. I've seen way to much of that practice over the past 10 years. It just doesn't cut it.

irishdude11

I reckon there are performance issues as well with the early versions of .NET. I have seen pretty straightforward applications performing terribly on a good specced modern machine. I can see no other reason for how the performance could be so bad apart from it being down to early .NET. You could not program in performance issues this bad lol.