Experienced Devs

4008 readers

13 users here now

A community for discussion amongst professional software developers.

Posts should be relevant to those well into their careers.

For those looking to break into the industry, are hustling for their first job, or have just started their career and are looking for advice, check out:

Logo base by Delapouite under CC BY 3.0 with modifications to add a gradient

founded 2 years ago

MODERATORS

snowe

jmk1ng

drewsiferr

-17

Why enterprises use .NET and C# technologies? (lemmy.one)

submitted 1 year ago* (last edited 1 year ago) by [email protected] to c/experienced_devs

26 comments fedilink hide all child comments

I looked for Senior Software Developer positions, and one of the things that I've noticed is that lots of enterprises look for people with experience with technologies such as .NET and C#.

I personally HATE Microsoft and their platforms. From my experience they take all the fun from developing by creating stupid compile errors with their stupid gigantic Visual Studio and buggy dependencies. Not to mention their ridiculous resources greedy and unsecured Windows OS! Also there are no healthy and independent communities around a their technologies. They don't open source much of their technologies so it would be easier to hack their tools, and harder to make security patches.

Why enterprises do that for themselves and for their developers?

Do you think enterprises will make a turn in this attitude?

you are viewing a single comment's thread
view the rest of the comments

[–] [email protected] 5 points 1 year ago (1 children)

Because code written 20 years ago on .NET and C# still works today, showing the stability of the platform.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago) (2 children)

I mean... as someone who's had to port some .NET framework software to .NET 6... yes... but.

20 years old .NET framework code will keep working, sure, as long as you can find and install the correct .NET framework runtime, but maintaining it might be a different matter... you can code .NET with notepad, if you feel like it, but for .NET framework code you will need Visual Studio, with the proper SDKs... which might not be available in the latest version of Visual Studio (on occasion I've had to install VS 2019 so I could compile old .NET framework code in VS 2022).

And when you get it to compile you still might have to deal with third party tools (Crystal Reports, for instance) that don't work in modern .NET or later versions of Visual Studio...

And of course then you want to add something new to the code, which is why you went through all that trouble to begin with... but the tools for what you want to do are only available in modern .NET, or as nuget packages that won't work with framework... and you'll have to migrate the whole thing to the latest long term support version of .NET... which sure, is several orders of magnitude less work than rewriting the whole thing in some other language, and heavily automated... but is still a whole process.

But then of course there's the bits of .NET framework that got deprecated during the transition (or in later updates), or the third party libraries that never got updated... and you'll have to find or implement replacements for those...

But yeah, once you've done all that your refurbished 20 year old code will still work today, and significantly better than it did before... and if it isn't too ridden with windows dependencies (WPF and the like) it might even be portable to Linux or Mac, or whatever. And it'll probably still work (and do it even better) 20 years from now.

[–] Buckshot 5 points 1 year ago

I'm working on migrating a lot of old .Net Framework code right now, we're generally going with a complete rewrite but that's more to do with poor architectural decisions and the fact a lot of it is VB rather than C#.

It's pretty impressive that code largely written up to 20 years ago is now running on a modern OS, and it's using the latest Framework 4.8 with all the latest security updates and I can open VS2022 and hit run and it builds and runs fine. Our issues are the maintainability of the code and how it was written rather than the framework itself.

Meanwhile, a few years ago now, I had a web project written in typescript, it was only about a year out of date and npm install failed. Turns out one of dependencies needed to build something with python2, updating that needed a new version of webpack and that broke something else that never got an update to the newer webpack. Installing python2 didn't work either I think but I can't remember why.

There's systems I wrote for .Net over a decade ago that I can guarantee are still running in production and haven't been touched in all that time.

In short, I think I'm agreeing with you. It's painful but it's possible.

[–] [email protected] 3 points 1 year ago* (last edited 1 year ago)

Meanwhile in Ubuntu-land, a Python2 script probably just straight up doesn't work at all.

"At least the .NET code continues to run today". And you can setup a 20-year-old developer VM running VS2008 in practice and code "the old way" to continue to maintain the old code (that still runs on today's machines). Meanwhile, you're FORCED to migrate the Python2 stuff in Ubuntu-land due to a litany of incompatible changes to systemd, X.org, Python2 vs 3 issues and more.

Not just Python2, but also Bash-scripts. (Weird changes to netcat, or ipconfig, or other tools that utterly bork old scripts).

Microsoft isn't as good at backwards compatibility as it used to be. But they're still leagues ahead of the OSS community on this.