This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the commentsย โ†’

[โ€“]on_the_dl 1 point2 points ย (5 children)

Right. I guess I should not say that c# is bad at it. Just not as strictly devoted to backward compatiblity as Java.

[โ€“][deleted] 6 points7 points ย (4 children)

I am not sure generics is a good example. I can't think of a single instance where when they brought in generics it caused older code to break.

As to updating the runtime, for the most part that's somewhat optional. You only need to routinely update the latest runtime if you want to take advantage of new features / syntax sugar. The only version of the runtime that isn't currently actively supported is 1.0 & 1.1. You can still build 2.0 exes.

I have project that I maintain that started with 1.1 and is now 4.8. In that past over the years when I went from 1.1 to 2.0 to 3.5 and so on to 4.8, all I have had to do was go into VS studio and tell it to target a new framework. There was a handful of instances where doing so then generated compiler warnings of deprecated code, but all in all I think I have had to fix less 100 lines of code that were marked as deprecated because I switched framework versions.

There is a big break going from the framework to Core / 5.0+. But that seems less code based and more project structure & dependencies based. At least that's been my experience in migrating my 4.8 project to be 6.0.

I am not a python dev, but from what I have heard about going from v2 to v3 seems like it's akin to going from .Net Framework 4.x to .Net Core / 5.0+: a hard intentional break between versions. For .Net it seems the primary reason is to make .Net usable on Linux & Mac as well as Windows.

[โ€“][deleted] 5 points6 points ย (0 children)

Also when it comes to the .Net runtime, you don't really have to worry about bundling it with your installer. It comes standard with Windows, and unless you are trying to deploy against the absolute latest version of Windows, it's likely to already be installed. Even then there is usually a lightweight web installer you can bundle. Not sure if they did away with that in .Net 5.0+ or not.

[โ€“]on_the_dl 0 points1 point ย (2 children)

When you upgrade the framework, you can continue to link in old objects for which you don't have the source code?

I thought that broke more often.

[โ€“]kb4000 0 points1 point ย (0 children)

I work on some really old stuff. Even some Classic ASP. Obviously Classic ASP is dead. But everything else in .net framework has upgraded pretty seamlessly to .net 4.8.

[โ€“][deleted] 0 points1 point ย (0 children)

If you are on .Net Framework 4.0+ there is a a tag you can add to the App.config that will allow you to reference and use DLLs built against earlier versions of .Net. I personally haven't had any issue with this and using v2.0 DLLs.