4 ms·

And .NET Framework. You can still run 3.5 applications, and 4.5 will also exist as long as Windows will exist.

JadeNB 2y ago
> You can still run 3.5 applications Given the discussion in a sibling (nephew?) thread (https://news.ycombinator.com/item?id=40755845 https://news.ycombinator.com/item?id=40755845), I thought at first that this was a description of how many modern, bloated apps you could run on a modern computer before the OS slowed to a crawl.
tialaramex 2y ago
And yet, as with so many other systems Microsoft can't or won't keep this up for newer versions. I spent part of Thursday wrestling with Graph code that it turns out has an older version of one Nuget package, and if you "just" upgrade it now all the authentication layer is completely broken and needs to be redesigned because it's apparently "better" with the "streamlined" modern version, but if you don't upgrade it nobody's documentation for the problems we're solving matches because they also moved a bunch of the extension methods to different places or renamed things, again you know for streamlining. Somebody else on HN said they don't rely on anything which has Semver and yet the major version is 4 or greater, because that means they were so wrong they had to change their API already at least three times so they've clearly got no idea what they're doing. I think I'm beginning to agree.
miki123211 2y ago
and Go. Go 1.0 code mostly compiles and runs just fine.
albertopv 2y ago
Not really the same, .NET Framework is a dead end, current .NET (former Core) is quite different, you can't port .NET Framework 4.8 apps to .NET 8
- neonsunset 2y ago
  You can. C# 1.0 is still valid syntax, and library authors can target both legacy and current day versions of .NET with netstandard2.0 target. Most libraries do just that. Moreover, there are still some applications that get to use modern runtime-independent language features and SDK-style projects (terse Cargo.toml-like project manifests, still XML but they are very readable) while targeting both .NET Framework 4.8 and .NET 8 at the same time (and everything in-between them). Hell, I've seen projects[0] which look relatively modern but for some reason still target .NET Framework 3.5, I do not condone that, but it is doable and sometimes there are reasons for it. [0]: https://github.com/Kevin-Robertson/Inveigh/blob/master/Inveigh/Protocols/Quiddity/Quiddity/Quiddity.csproj#L4 https://github.com/Kevin-Robertson/Inveigh/blob/master/Invei...
  - albertopv 2y ago
    You can do (almost) everything with enough time and resources, but it can be tough. WCF, without CoreWCF couldn't migrate until 2022 release and .Net Core 1.0 was released in 2019. EF Core is different. WPF, ASP .Net WebForms... Microsoft Message Queues usage is a no go. So yes, you can, not always, not easy, often not worth.
    - neonsunset 2y ago
      (2016) https://devblogs.microsoft.com/dotnet/announcing-net-core-1-0/ https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...

> You can still run 3.5 applications Given the discussion in a sibling (nephew?) thread (https://news.ycombinator.com/item?id=40755845 https://news.ycombinator.com/item?id=40755845), I thought at first that this was a description of how many modern, bloated apps you could run on a modern computer before the OS slowed to a crawl.

tialaramex 2y ago

And yet, as with so many other systems Microsoft can't or won't keep this up for newer versions. I spent part of Thursday wrestling with Graph code that it turns out has an older version of one Nuget package, and if you "just" upgrade it now all the authentication layer is completely broken and needs to be redesigned because it's apparently "better" with the "streamlined" modern version, but if you don't upgrade it nobody's documentation for the problems we're solving matches because they also moved a bunch of the extension methods to different places or renamed things, again you know for streamlining. Somebody else on HN said they don't rely on anything which has Semver and yet the major version is 4 or greater, because that means they were so wrong they had to change their API already at least three times so they've clearly got no idea what they're doing. I think I'm beginning to agree.

miki123211 2y ago

and Go. Go 1.0 code mostly compiles and runs just fine.

albertopv 2y ago

Not really the same, .NET Framework is a dead end, current .NET (former Core) is quite different, you can't port .NET Framework 4.8 apps to .NET 8

neonsunset 2y ago
You can. C# 1.0 is still valid syntax, and library authors can target both legacy and current day versions of .NET with netstandard2.0 target. Most libraries do just that. Moreover, there are still some applications that get to use modern runtime-independent language features and SDK-style projects (terse Cargo.toml-like project manifests, still XML but they are very readable) while targeting both .NET Framework 4.8 and .NET 8 at the same time (and everything in-between them). Hell, I've seen projects[0] which look relatively modern but for some reason still target .NET Framework 3.5, I do not condone that, but it is doable and sometimes there are reasons for it. [0]: https://github.com/Kevin-Robertson/Inveigh/blob/master/Inveigh/Protocols/Quiddity/Quiddity/Quiddity.csproj#L4 https://github.com/Kevin-Robertson/Inveigh/blob/master/Invei...
- albertopv 2y ago
  You can do (almost) everything with enough time and resources, but it can be tough. WCF, without CoreWCF couldn't migrate until 2022 release and .Net Core 1.0 was released in 2019. EF Core is different. WPF, ASP .Net WebForms... Microsoft Message Queues usage is a no go. So yes, you can, not always, not easy, often not worth.
  - neonsunset 2y ago
    (2016) https://devblogs.microsoft.com/dotnet/announcing-net-core-1-0/ https://devblogs.microsoft.com/dotnet/announcing-net-core-1-...