| ▲ | jonathanlydall 7 days ago |
| C# devs can open decade+ old solutions without issues, maybe this is just "normal" for the JavaScript ecosystem, but there absolutely exist other ecosystems which don't absolutely waste your time in this way. |
|
| ▲ | me551ah 7 days ago | parent | next [-] |
| Not true for the entire C# ecosystem. I tried rebooting a Xamarin project I coded a couple of years ago. Had to spend weeks upgrading it cause Microsoft decided to discontinue Xamarin and force everyone to use
NET MAUI |
| |
| ▲ | neonsunset 7 days ago | parent [-] | | This has to do with specific framework and does not translate to the overall experience (for example targeting iOS is pain because Apple deprecates versions quickly, so downstream dependencies have to match this too). You can open and build a back-end application that targets e.g. netcoreapp2.1 (6 years old target) just fine, it might require installing you an archived SDK for the build to succeed (which you can download regardless, it will complain that it is EOL though) but it's an otherwise simple procedure. For library code it's even easier - if you have netstandard2.0 target, it will work anywhere from .NET Framework 4.6.1 to the latest version without requiring any maintenance effort whatsoever. On Windows, Visual Studio will happily work with .NET Framework 3.0 (which is ancient) and more. | | |
| ▲ | thrw42A8N 6 days ago | parent | next [-] | | If you used pure Node.js, you wouldn't have any problems whatsoever, too. | | |
| ▲ | neonsunset 6 days ago | parent [-] | | Unlike Node projects, your dependencies don't break - they stay on nuget.org, and the projects compile just like they did when they were first implemented. Upgrading dependencies and project target is subject to the same restrictions as in other good languages. I know for sure that I can clone a random project on Github, hit `dotnet build` and usually expect it to work on the first try. The rate of bitrot for average unmaintained JS project cannot be compared. The average dependency graph of a .NET project is going to be 10 times smaller too. | | |
| ▲ | MrJohz 6 days ago | parent | next [-] | | This is true for NodeJS as well - dependencies on NPM cannot be removed, so at long as NPM keeps running, and as long as you've got a lockfile that precisely specifies all dependencies, you shouldn't run into problems running older projects. (Certainly I have never had an issue with this - the problems, if they occur, are always around upgrading. And like you say, this is subject to much the same issues in every ecosystem). If this isn't enough, there are tools like Yarn which encourage vendoring dependencies to ensure that as long as you have a copy of the repository, the yarn CLI, and a valid version of NodeJS, you can always run the project. | |
| ▲ | thrw42A8N 6 days ago | parent | prev [-] | | Yeah, that's nice, unfortunately it's the built-in Microsoft stuff like WPF that keeps breaking between versions. |
|
| |
| ▲ | a1o 6 days ago | parent | prev [-] | | Note Microsoft still removes downloads of previous versions of Visual Studio that aren't the latest - now you can only download VS2022 unless you have some mysterious paid account that has access to those - I don't have in either my personal or my corporate so I don't know the details | | |
| ▲ | trinix912 6 days ago | parent [-] | | This is true and is a pain if you’re stuck on something like Windows 7/8.1 (or 10 in the future). The installer being a web installer that auto-updates on start also means that downloading an older one doesn’t help at all. The only way seems to be to pirate the Enterprise offline installer which of course isn’t really an option. |
|
|
|
|
| ▲ | timrobinson33 7 days ago | parent | prev | next [-] |
| As it happens I've recently upgraded a 2 year old project with both node and C# It was open much the same in both. If you're happy using outdated and unsupported components with security issues AND you can get hold of the right version of the dev tools and plugins AND your hiding environment still supports the old platform, you can maintain the old version with minimal change. But should any professional developer do this? |
| |
| ▲ | HeyLaughingBoy 5 days ago | parent [-] | | It depends. In domains where software is expected to run for years, if not decades, it's common to archive the entire toolset, along with libraries and SDK's in case you need to fix a bug/add a feature 10 years later. Obviously, in this case you can't have dependencies sitting somewhere on a server you don't control. There are also situations where this is forced by regulation: you need to recreate build xxx.yyy.zzz 7 years after release because a customer reported a serious bug and it needs to be reported to the relevant regulatory agency and investigated. |
|
|
| ▲ | david_allison 7 days ago | parent | prev | next [-] |
| Not any more. Security vulnerabilities in dependencies now break the build by default. It's arguable whether this is the correct decision, but it makes things slightly harder than they used to be |
|
| ▲ | toyg 7 days ago | parent | prev | next [-] |
| > C# devs can open decade+ old solutions without issues For some definition of "without issues"... |
|
| ▲ | nisegami 7 days ago | parent | prev | next [-] |
| I wish I lived in the world you described but trying to onboard a new dev onto an existing (edit: ancient) C# project at my job is frequently a multi-day endeavor. |
|
| ▲ | JansjoFromIkea 7 days ago | parent | prev | next [-] |
| I think there's much bigger deviations from long term stability the closer you get to a GUI as things deviate further from ideals into brute force hacks for stuff to look right. Can remember trying to update a Unity project so it'd be still buildable for 64-bit Mac devices. The very first version bump I done resulted in several critical libraries no longer working and there being no clear alternatives to swap in. |
|
| ▲ | horsawlarway 6 days ago | parent | prev | next [-] |
| As someone who has migrated old ASP/silverlight projects and BHOs... seriously, this is complete bullshit. This depends highly on what dependencies are in your C# solution. Same for his node project. If he'd stuck with dependencies that are just plain js - I'd bet money his project would have installed & built just fine. By the time you're hitting the native addon apis and doing things like compiling python and C/C++ code... you're going to feel all the pains of those ecosystems too. |
|
| ▲ | thrw42A8N 7 days ago | parent | prev [-] |
| Lol, I left C# because I couldn't solve this issue and in Node.js it's particularly easy - just keep a nvmrc file and a dependency lockfile. |
