1

For maximum compatibility for applications, it would make sense to target the oldest version of .NET I can. I know where major features (such as LINQ being v3.5 onwards) were introduced, but there are lots of small changes I have no idea about.

The only way I have found of checking what version I can target is by selecting the oldest one, reloading the project, building, then trying a newer version if it fails. Is there a way I can 'scan' the source code for a project and get the lowest compatible .NET version back?

MikeS159
  • 1,884
  • 3
  • 29
  • 54
  • 3
    Since there are only a handful of versions, I doubt that there is a quicker way to do what you want. Even if there were a tool for this, downloading and running that tool probably takes more time than "compile-and-error" testing a few projects. – Heinzi Mar 24 '16 at 14:15
  • 1
    The lowest version you can target is 4.5.2 Earlier versions have already been retired (2.0) or are about to be retired this year. 4.5.2 is the only one that support TLS 1.2 too, which means you *have* to use it if you want to talk to any popular REST service like Google – Panagiotis Kanavos Mar 24 '16 at 14:15
  • @Heinzi you are probably right, its a bit of a pain if its a large project that takes a while to compile, but everything I write only takes a few seconds. – MikeS159 Mar 24 '16 at 14:18
  • @PanagiotisKanavos All versions before 4.5.2 are no longer supported, but they can still be targeted. If you wanted to run on Windows XP you would need to target Version 4.0 – MikeS159 Mar 24 '16 at 14:19
  • @Mike159 I know of no supported Windows version called XP. Seriously, that's why I mentioned TLS 1.2. It's not that *Microsoft* has retired these versions, it's that the rest of the world has stopped using these technologies. Are *you* going to take responsibility for a security breach because you had to use SSL? – Panagiotis Kanavos Mar 24 '16 at 14:23
  • @PanagiotisKanavos Point taken. I try and avoid unsupported stuff where possible, but unfortunately some people aren't moving away from XP that quickly – MikeS159 Mar 24 '16 at 14:30
  • The only point in targeting the maintenance releases (4.01, 4.02, 4.03, 4.51, 4.5.2, 4.6.1) is to *force* your user to update his .NET version if he otherwise disabled Windows Update. Which is not a bad idea, but then it only makes sense to pick the one that matches the version you actually tested. Which right now should be 4.6.1 on any dev machine. If you don't want to force it then only targeting 4.0 or 4.5 makes sense, the additions to the api in the maintenance releases are small and obscure. – Hans Passant Mar 24 '16 at 14:37
  • 1
    @PanagiotisKanavos "_...rest of the world has stopped using these technologies._" If only! Back in the real world, maybe he has customers who are still using XP, there are enough of them around! https://en.wikipedia.org/wiki/Usage_share_of_operating_systems#Desktop_and_laptop_computers. XP is only just behind OSX as of Jan 2016. Of course he's not going to take responsibility for security breaches due to his user's decision to continue with XP, that's just silly. I still use some software on XP VMs, and heck even W2K. My choice, and it's nice to find apps and utils that can still run there. – beercohol Mar 24 '16 at 14:51
  • This question cannot be answered based on the comments. What is your goal then? If you intend to support end-of-life platforms such as Windows XP, you deprive the others of giving a meaningful answer. Microsoft will keep supporting .NET Framework 3.5.1 and 4.5.2 and above, so even if you want to target .NET 2.0 profile it is supported on any supported Windows releases. – Lex Li Mar 24 '16 at 15:16

1 Answers1

0

First I think this is answered here: How can I test the backward compatibility of API between .net assemblies

tl;dr: APIChange Command

Community
  • 1
  • 1
JeremyCodes
  • 18
  • 5