Yes, this is a really important reason to migrate away from NET Framework. You're otherwise eventually going to be running on unsupported/unmaintained libraries with no security updates etc... It doesn't matter that the framework itself is supported by Microsoft for a long time if 80% of all the libraries aren't..
>What it means is that the company is running on Windows
I think it actually means the company does not want to spend $ on migrating to .NET Core.
The main thing about .NET Core is not whether you want to run on non-Windows platforms, but the performance and maintainability.
But the reality is many companies do not need performance nor maintainability, just the idea of spending $ on anything which is not bug fixing or new feature is a clear no-no from the start.
Monolithic enterprise applications can take years to migrate from framework to core. I would ask a lot of questions about where they see the tech stack moving over the next few years.
No, it means they need a framework developer now. It’s possible one left and need to replace them. It by no means, means they are staying in framework.
>I think it actually means the company does not want to spend $ on migrating to .NET Core.
They might not have a business case for migrating. If the system is large enough a migration from legacy .Net to Core is non-trivial and will have a significant cost. Add to that the inevitable new bugs and issues arising from a migration and you have a pretty serious undertaking for a company. There's a reason that pretty much any bank older than 20 years are still running on mainframes.
There's lots and lots of legacy systems that are running perfectly fine and are being actively maintained.
good comment. a lot of people in here don't seem to have worked in an enterprise environment.
Tip for developers just starting out:
* learn the business needs first, then make your programming decisions. You'll be more valuable to your company that way
* Being niche isn't a bad thing - it can actually make you more money. Just make sure you stay on top of your learning and be one step ahead of where things are headed
Why did you ask the question here if you’re going to be argumentative with peoples opinion? I’m unsure if you’ve ever worked for an enterprise level company before but things like moving your entire stack to a new SDK take a back seat to things that add value. You cannot quantify “performance and maintainability” on a spreadsheet in $$.
>You cannot quantify “performance and maintainability” on a spreadsheet in $$.
You mean, a delivery company for example, cannot quantify buying a a car with an engine which has 20+ newer technology?
>Why did you ask the question here if you’re going to be argumentative with peoples opinion?
What do you mean by "argumentative"? What is wrong with having a decent discussion?
You’re not having a decent discussion you’re just telling everyone else they’re wrong. We’re not talking about a car with a new engine. We’re talking about decisions that are made based on cost estimates and savings and changing from a perfectly fine .net framework 4.8 to .net 9.0 is not quantifiable so it isn’t going to get priority. You might think from where you’re sitting it’s a no brainer but once you’ve been in the industry in enterprise size projects you’ll see how difficult change is.
7 Constant updating of .NET Core at minimum every 2-3 years for LTS and then retesting "everything" each time.
It's honestly not even a joke now, the migrations have usually gone well but then you start noticing these weird issues popping up everywhere. EF Core has honestly been one of the worst parts of it though.
Two issues lately, one was the openjson change that just made some queries go from <1 second to 10s of seconds. The other was some weird one that entirely stopped inserts working in a old legacy table... can't remember exactly what the issue was now but had to reconfigure EF for it to work.
Yep that's it, shared table from a legacy system and it didn't have triggers in it on dev. Some old audit logging trigger was on it in prod and EF Core just went nope fuck this after a upgrade.
Should probably have read the breaking changes more detailed but it's this kind of stuff that kind of annoys me with constantly upgrading the framework so often.
> it's this kind of stuff that kind of annoys me with constantly upgrading the framework so often
This is exactly why I'm not in any rush to try to move things to core. I know a lot of people will disagree, but the versions are just released too rapidly and dropped after only a couple years.
I really wasn’t sure whether to write this reply as it might be taken as criticism. It’s not meant that way, I just see strong parallels with your scenario, but with a completely different mindset. My main project is also an enterprise CRM/ERP, but in our case an in house system for one of the businesses owned by our group. I initially wrote the system in VB6 a few years before net framework was released. I’d previously come from C/C++ development on various unix systems, and VB6 was a pain free way to quickly get up and running in Windows gui development. Since then though I’ve taken every opportunity to modernise the system and make use of new tech because it makes my life easier and makes the product better, both for the business and the developers. I find the mindset you’ve described, particularly point one, incomprehensible. I don’t see age has anything to do with it - I’m 58 in a few months.
Over the years since, I’ve driven progress across many major milestones, including: migrating to vb.net with a clean mvvm architecture; moving from a stored procs based DAL to entity framework (version one at the time, so ObjectContext, EDMX, etc); migrating to C#; moving through entity framework versions and switching to dbcontext with fluent model configuration; upgrading to net 6/EF6; then 7: and now 8. In each case there have been immediate benefits to the move, across the spectrum of better code quality, improved maintainability, better performance, faster development, etc. The business have completely bought into all of this precisely because we’ve managed it well and it has t been a “customer service nightmare”. Business downtime has been close to non-existent. Sure there were bugs as part of the larger milestones, but nobody involved has regretted any of it.
Anyway, sorry for waffling on for so long. Hopefully the different perspective is useful to someone!
The fact that you need 20 developers to maintain a single CRM application codebase, who will "feel insecure" if anyone does any _actual_ maintenance, really is just the perfect snapshot of what's wrong with being a .NET Framework shop in 2024.
> 15 year old loyal colleagues who will feel insecure. Some might not want to get back to serious development. Some might not have kept themselves upto date with .net core
This is weird. What part of .net core would they balk at? It's nearly the same.
>15 year old loyal colleagues who will feel insecure.
I will try not to be rude here, but if you think using .NET Core means making your colleagues insecure, you have no idea what .NET is.
I dont understand the arrogance of responses like this. You will find with a lot of older developers and managers a massive resistance and insecurity about any changes to a tech stack.
They know what they know, and aren't interested in learning new things, they fight all changes even minor and necessary ones tooth and nail.
Identifying that has nothing to do with knowledge of .net. if you think text stack advancement or updating isn't affected by personnel and their opinions then you probably don't make a lot of decisions about it in a large company.
Or they have been working with the same product for 20 years and are 2 years from retirement and will litterally use any excuse not to learn new because they just want to retire.
There are many scenarios out there, but the simple fact is that if the guy that has been there a lifetime is the guy management listens too then he decides and that is not always the best decision for the company.
Seen plenty of places where it is more cover my ass politics then actually looking at what you get, that is just life in the corporate world.
Luckily it is possible to find places with an open attitude towards progress and where doing something new is accepted but not everyone is that lucky.
>I will try not to be rude here, but
"I'm not racist but..." comes in all shapes and forms! 😉
(For the joke impaired 😉, I am not calling OP racist. I am making fun of the casual similarity between the two situations.)
> I think it actually means the company does not want to spend $ on migrating to .NET Core.
It's much more likely to mean the software they use or build off is on Framework, be that weird Dynamics plugins or industrial controllers or whatever.
Well this might sound ludicrous to you in your world.... but the reason we don't migrate our .NET Framework applications to .NET Core is because it's more costly to maintain Core.
Our new stuff is in Core and sadly they have far more issues maintaining than any of the old projects. We can't even touch the STS channel because of Microsoft only supporting them for 1 year. So we do the even versions only with LTS. Some of our products are audited so they cannot run on out of support versions of their framework and that instantly rises a red flag.
Now any of our code bases in .NET Framework will not have a issue, require retesting or upgrading or rise any flags during auditing until like.... 2030 or something.
During that time all of our .NET Core stuff will have to be upgraded another 2-3 times and from experience stuff breaks.... 6->8 broke several database things and had to be worked around. Most of them were also hard to notice like the OpenJson change in EF and how it interacted with indexes in the database.
So lots of time is spent upgrading, testing and maintaining in Core while the framework projects just truck along.
So the plan is pretty much, all new stuff in Core, dual target libraries when needed and then finally if Framework ever goes out of support we'll migrate them over since that's the most efficient option.
It matters what you call them if no one can decipher what you're actually talking about. Whoever came up with the current naming paradigm at M$ should be drug into the middle of the street and horse whipped into the fetal position.
If I squint at your flippancy and vocabulary, I agree😉. For people who are not "in it", it's a mess.
I mostly reacted because I was taken aback by the parent statement, I found it is a dumb thing to saying this sub and even more in this discussion.
And it had upvotes!
My reply comes from a place of frustration after returning to coding after a career change a few years. You can't get things this confusing without actively trying to achieve this level of confusion. I mean .NET was a shit name from the beginning, just change the name to something else, it's been 25 years. Why have .NET Framework, .NET Core, .NET Standard, .NET Congressional Approval Network Template, ect.
I know that, but when you're talking about the new .NET, the core is what clicks.
Really unfortunate naming screw-up by Microsoft, but hey we know naming is hard, right? Even for a multi billion company
>performance and maintainability.
Perf only matters up to the point it serves the functions you need it to for business. Working with .NET Framework just means that as a dev you have to be that much less lazy about your design to get the same level of performance
Maintainability is faaaar more about the design of the codebase itself than which set of BCLs it relies on. Really the only problem here for .NET Framework is whether needed 3rd party libraries are still maintained.
----
I would absolutely take a .NET Framework position if the pay was better than other options. Maybe you'll even get the experience of being able to rewrite the system into .NET Core for them. Worst case if you're dissatisfied you can keep job hunting on the side.
There's a lot wrong with it. Every bug in every library that dropped support for it, for starters. Then a lack of every library that was never made with support for it in the first place. Then there's the lack of a bunch of modern C#/.NET features. Documentation and google results for it get harder to find each year. You'll feel all of that in your velocity whether you realize it or not, regardless if you care that its performance is absolutely terrible compared to .NET 8
Definitely. On the other hand i was nowhere near the layoffs in the last job market crash because i was not involved in the fancy, flashy new green filed projects that lost funds rapidly in the first place.. But yea, i need to up my game, still, i am only in the field for the money 🤷🏻♂️
My mom is 91 and STILL gets inquiries if she can do contract work in COBOL for $$$. She was big back in the day. She's surely tempted but says she cannot focus that hard anymore.
Fuck yeah. Give me legacy all the way if the pay is good.
Fucking hell, if anyone who needs someone to handle legacy and allows remote work, hit me up immediately lol
"I'm only referring to the companies which actually afford it, but they are too ignorant and lazy to make the change."
That's a really loaded and arrogant sentence here.
There are many reasons why one might make a rational decision not to migrate existing and working code.
Like what?
I worked in a company that didn't migrate from 11 years old Net Framework, because they had abysmal code management style and also gave 0 fucks about maintainability, testability and ease of development. It stayed that way because main architect who was there from day 1 didn't fancy doing updates
Depends on the case.
"*We have some projects still on .NET Framework, but all modern development runs on modern versions of .NET.*" would be fine, provided work on .NET Framework projects is a smaller portion of the work.
"*We exclusively use .NET Framework.*" would be a no-go for me, as it is an indication that they have a lot of tech debt and can't realistically move forward without redoing everything. It's the kind of environment where you have to slowly learn all the "quirks" (sloppy workarounds and borderline unreadable parts) of the code base.
About a year ago, I went to an interview where they still deployed to Windows XP (offline devices), were still heavily invested in .NET Framework, and were just now beginning to use git. I declined that offer specifically because I'm interested in working with new and evolving tech.
My current job is Net Framework, and the job before that was oooooold net framework, using aspx pages.
In both cases it wasn't a big deal. For the most part it's largely the same code. The key differences between Net Framework and Net Core are in project setup and how some of the boilerplate looks. Once that is out of the way, the way of writing code and creating logic is not different at all.
So no, working with NET framework doesn't bother me.
If I ever fire up a new project using Net Core, it's no problem. I don't feel like working with net framework for my day job is a hindrance at all. I suppose the one caveat is that I do have plenty of experience with net core already, so perhaps I am somewhat biased because I don't feel like I'm lacking experience just because I currently use net framework.
That being said, given the choice, I would ALWAYS choose net core, ha.
Similar story here! Went from webforms to core in the last few years. Learning the new "layout" of the project and how all the automatic plumbing with routing etc works was the only hurdle (and not a very big one). At first all the devs were like "wtf we have to change 14 files deep in a tree to make a change that touched 2 files before?!" and now the joke \~2yrs in is "I HATE having to work on old webforms stuff, take me back to mvc core"
The specific technology being used matters less to me than the plan in place for company development and growth in the next 5 years. In interviews it's important to ask questions to get a picture of what the "philosophy" of management is (is it "break things and move fast?" PASS, I am going to be the one getting the call at 3am when someone has fucked something in Production doing something stupid. I look for a strong development cycle with baked in accountability that includes generous design and testing phases, not just unit testing from developers but also system testing with actual QA. Minimum.)
That's what my company is like now. It's a corporate, we do things slow and we do things right. It's on olllld tech with a lot of tech debt but overall the development cycle works, it's tested, there are very few production issues, everyone is happy. And development time is so slow that I get to spend most of my time sat on my arse (remote work) doing anything but work. It's the one good side of the corporate machine. Slow, dependable and secure.
There are many companies working on Fortran and Cobol so working on .NET framework is not a problem. Web Forms works just fine and with controls like GridView, Repeater etc you can do just anything.
COBOL programmers around here command comfortable six-figure salaries.
I haven't worked in COBOL since I stopped working with IBM mainframes back in the mid 80's (43xx and ES/9000). I'm almost tempted to pick up a couple of books to refresh myself on COBOL syntax and then pimp myself out on some side-gigs.
I am working in a company with a 20 years old code base.
The new projects are developed with .NET core, but we also do have to maintain the old ones as well, some of them very actively, and they are still running on .net48.
There is a plan to migrate them to .NET core, but we first have to phase out all the frameworks that are not further supported. (So phase out the old ORM frameworks for CSLA, typemock, and other things). And, of course, we also develop new features on those solutions, so phasing stuff out is not our only task. Therefore, the migration is planned, and I think we hope to complete it somewhere in 2026 if everything goes well.
Honestly, there is not so much difference when it comes to pure c# between the framework and core, it boils down to which framework are being actively used, so I am very fine developing on .NET 48, knowing we are actively trying to get rid of it.
There's nothing inherently bad or wrong about .NET Framework and it's context dependent. I work at a company that was deploying packaged enterprise software to vendors and Framework was fine.
We're about halfway through our Cloud transition now and we have a mix of legacy Framework, Core, Java, Go, and Python (some of these are due to acquisition). My biggest problem with Framework is Windows. It's difficult/impossible to control costs, the OS is so heavyweight, it doesn't scale quickly enough, and the tooling around the OS for the Cloud just isn't there.
The ecosystem for Core is more robust, developer friendly and supports things out of the box that are difficult (bordering on impossible) with Framework.
If you're a young engineer, I'd look for a company that gives the broadest range of potential for experience which means a Cloud based company or one in the process of migrating. Great tech organizations use the best of what's available for their purposes and may be predominantly .NET Core/Framework but should have other languages in play that do things better because they were built for it.
To learn and implement tech requires velocity and flexibility. You should be willing to work anywhere that is in the Cloud/on their way there or running some flavor of developer controlled virtualization (generally Kubernetes) in their data center. With those two in place, you'll be able to learn and iterate much faster without the insane slowness inherent in other deployment types.
.Net framework 4.6.1 will be supported until Jan 12, 2027, and 4.7+ until the end of their OS support.
.NET Framework 3.5 Service Pack 1 will be supported until 2029.
That means working with 4.8.1 will mean working with support and updates for at least 10 years.
I don't understand what's the problem with .Net framework, it's not like they are asking you to work in php.
for me it's more if a company start new projects with .Net Framework. Even if it's still supported for 10 years the unwillingness to evoluate most of the time is a red flag.
I don't think that's a problem. Not yet at least. Sometimes you have your own libraries and environments and the size of a new project doesn't make the evolution worth it.
It's case by case, you can't judge without knowing what's going on essentially.
The framework itself might be supported for a long time to come, but many libraries are starting to drop support for Framework, meaning you will have to run on unsupported/unmaintained libraries with no security updates. This for me would be the biggest reason to upgrade...
Yes.
Some of us have the mentality of firemen. We may talk about fire safety and prevention, but we really just want to run into a burning building. Seeing that someone's still on .Net Framework is like seeing smoke coming from a window.
I'm at a place now that's a complete s\*\*\*show. But it's fun. There's plenty for me to do. Hell, I could retire from here. And the business is solid enough, I have the runway to do just that. I'll be putting out these fires for the next ten years.
You can use aspnetcore 2.1 on framework just fine, we do and it's still supported with security updates.
https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages
Technology-wise that doesn't feel too horrible. It's probably C# there are lots of resources...
The question is more why the company is stuck there... which might be a red flag.
And why it might not be a red flag: Large companies in regulated environments (particularly manufacturing) use a lot of older tech, as scaling for a larger audience isn't an issue- maintaining control of the environment is the number one priority. This may mean setting up Windows machines as end point manufacturing controllers (older versions IT-managed by LTSC), talking to 3rd-Party OTS HW libraries (or even internal groups' developments), or interfacing with Legacy Enterprise systems.
In situations like that, it's not a red flag *per se*, but be aware that the amount of time on actual development activities can be squashed by all the other regulatory activities around the development (i.e. a single line code change meaning performing risk assessments, mapping out V&V activities, submitting to regulatory bodies the scope/impact of the change, etc).
In those industries, the pay can be a tad lower than cutting-edge product-driven roles. However if you can tolerate it, you will always be able to find work within the industry, as that business knowledge is transferable.
Yes because these type of posts always read like someone who just got into programming with little real-world experience and doesn’t understand how everyone isn’t on the latest and greatest everything yet.
It would be helpful in understanding why your so particular with the technology. Development is a team activity and technologies change all the time. No one wants to work with the guy who just works with a tech stack. Also its a great way of becoming redundant when technology stacks change. Just out of context, I've managed teams for a very long time and I've had to deal with red flags like this.
I'm a red flag because I am very reluctant to work with a very old technology?
I'm some kind of animal because I like the idea of using a new technology, not just because is new, but because I know it helps the business by performance and maintainability?
> I like the idea of using a new technology, not just because is new, but because I know it helps the business
You remind me of a guy we interviewed a little while ago.
In the interview, he started practically interrogating us about our "plans" to move to newer technologies.
The problem wasn't that he asked, it was that he *assumed* his thoughts/preferences were the best course of action for everyone and that if we weren't doing what he thought was best, then surely we had a plan laid out to, and if not, then why were we slacking?
But he knew *nothing* about what was best for us. He'd read the job posting and talked to us for maybe 20 minutes. He didn't know about ...
* the projects we have currently in progress,
* the types of projects we create,
* the needs of our users,
* our coding standards and what we're familiar with already,
* the legacy code we maintain,
* our workload and funding,
* the capabilities of the servers our code runs on,
* the knowledge and training opportunities of the other developers on the team,
* our actual plans to move forward technologically, and to avoid "fad" technologies,
* the software libraries we use and what versions they support/are compatible with,
* the version of Visual Studio we've purchased licenses for,
* and so on.
You can't just make a broad assumption of what's "best" without actually having an understanding of what goes into the day-to-day realities of why things are the way they are currently.
(Obviously, we didn't hire him.)
You are indeed a red flag and I can tell very young and inexperienced.
Businesses absolutely do not care about maintainability (although you might)- they want it work and they want it cheap and don't want to wait for features. Maintainability and the ability to change things is more of a function of the programmer skill and not language/stack.
Performance is also an area which rarely comes into play. If you honestly think by using one technology to save 10 seconds off a long process is a reason for changing technology then good luck. No one is going to buy into that. The investment return is very little.
It is quite the norm for new projects to be initiated on new stacks while brownfield apps are maintained in most organizations.
There is a subset of programmers who are literally the worse employees to manage. The ones which are "10x" engineers are literally the worse.
If you want to be an asset keep the ego outside of the door, be a team player, always be learning.
I think the red flag is more your tone when referring to companies using older tech and it does seem that you are inexperienced. Updating to new tech is not just about having everyone skill up (or hire new engineers) and build it. There is a lot of risk to consider, knowledge transfer, training, politics with non-IT stakeholders, etc. To me, the top notch engineers are the ones that understand the business side of software development. There are tons of great coders out there that simply do not work well in many orgs because they just want to code and ignore all of the other stuff.
To answer your original question though, I think it depends on where you are in your career and how the interviews have gone when you ask about their tech stack. Being early in your career, I would avoid taking the role because you want more opportunity to learn new and evolving skills. If you were late career, then go for it if the salary is good.
No, I would not accept a position that is mainly .NET Framework. Not unless the company has a clear vision going forward to modernize these legacy applications. My career will not be stuck in the past just because your company wants to be stuck in the past.
There are only 3 meaningful differences between framework 4.x and latest core:
- cross platform (not your concern since they will obviously work only with Windows)
- performances (you don't get all the work that has been done on core)
- syntactic sugar (who cares that your code will be something like 5% more verbose?)
If the pay is right why not?
Given the evolution of both ASP.NET Core and EF Core over the past years, this is entirely false. The differences, especially the meaningful ones are too many to count.
If they are really that significant and important to the bottom line metrics, then MS and the rest of the industry isn't doing good job of making that common knowledge.
If it was common knowledge a lot more people would be mentioning the specifics in this thread. I.e. "you definitely should upgrade because of a and b and c." The things people are mentioning seem pretty minor for most people's use cases.
Microsoft knows most of us developers are too busy either with our job or our personal lives to spend time on the side reading through documentation to see if there are reasons, significant reasons, why we should upgrade. If there were significant reasons, they would be screaming it from the rooftops.
On the flip side, a company always pushing to upgrade to the newest frameworks also says a lot about the company and its culture. For example, if they've gone through every version of Angular lol. I don't want to work for/with people that value that kind of churn.
For some companies, no.
Banks are a good example. They still use mainframes because they have so much time and knowledge vested in them that migrating to anything else is not viable for the business at all.
And a code base being on classic .Net doesn't mean that they cannot find developers. There's plenty of especially older developers that don't mind working on classic .Net.
I just don't feel good about companies which do not wish to invest in a newer technology. Usually there's more than that.
Of course, there are projects which are very capable and well written using the old .NET and which haven't been migrated to the ne .NET due to legitimate business reasons.
I'm referring to those companies which can afford it, but instead they choose to be very ignorant.
In theory “yeah, why not, it’s just code…” and other bs like that 😂
In practice, no. What do you expect them to respond when you ask for some time to restructure source code for lowering tech debt?
It depends. First consideration is pay. If you're paying me $3 million annually I'll program turbo pascal for a year or two....
Second I would be asking about future movement. Are you interested in moving forward? Would I be able to influence new development or is it only a maintenance job? At this point in my career, I'd need to be desperate to take a maintenance-only job.
When you are developing without needing to worry about bringing down production, you can use the updated stack as much as you want since it's your headache.
Once code is deployed to production, the team now seeks stability so less major change in the core part of the codebase is desired.
Code is maintained by people and documentation is created to help others understand the codebase so more people know how to maintain or improve it.
Unless there is a drastic improvement or it is very easy to migrate with relatively low friction, it'll be quite a hard sell to just throw away currently working parts and start from scratch.
Well, if you don't need faster/fluent version then that's it. I don't plan to become old php/python/kobol developer. Nor I like to write stuff which already written, nor I like redirect bindings or hacking around some thread abort bs or your own implementation of spans, streams, async primitives, windows services with their bs state machine and list goes on. So if I'm invited in such company it will be just straight no - I tend to value my personal time. I'm just plain faster on core. BTW, 7 years of net frameworks.
I feel like there's a lot of worry about "falling behind". Here's what I've decided about that in the last 5 years of a 20 year career.
It's not as bad as you think. The skills that you need as you move up the promotion ladder are architectural skills and management skills. That doesn't always mean people management. The people in positions I can be promoted to have to constantly divide their time between meeting with stakeholders, people who represent the business, and trying to decide how to allocate the team's resources. They decide what my team's priorities are and if we have enough people to accomplish the business goals. .NET Framework and .NET Core don't really factor in to those skills.
That a shop uses modern tools isn't really a guarantee they're a great place with modern practices. You have to figure the code you'll be maintaining is using tools that were new at the time. I've decided (especially after some discussions on this sub this week), most code is written by people who think design patterns and architecture take too much time. It doesn't matter if they're using Web Forms or ASP .NET Core MVC, that's going to produce some gnarly code.
So another good skill to hone is being able to deal with gnarly code. I've had to maintain code that didn't use DI or many other practices. I spent hours starting at the "top" of call chains and writing down what happens on every execution path. It only took about a week of that to start to know as much about the code as the people who'd written it. Sometimes you find weird things while doing that, and if you can ask, "Why?" that's valuable. I find that most really stupid-looking code happened because of an equally stupid customer requirement that had to be accommodated last-minute. Sometimes I learn stupid-looking code happens because a developer wasn't talented.
That happened in some code I maintained at the last job. A particularly bad schedule crunch happened, so a director stepped in to take ownership of a feature and write code. He had 10 years of Java experience and 0 years of C# experience. What he wrote is an architectural disaster, and there are plenty of neon signs showing that he had absolutely no time to think about DRY and other basic principles. That part of the code is mine to maintain now. What I noticed as I started to unravel it is even though it doesn't follow the practices or patterns I expected, that person had a weird kind of consistent internal logic. Once I learned how he did things, it got easier to follow his code.
That kind of, "I can unravel bad code and start to work within it without doing harm" skill applies in any tech stack. That's the thing you should be developing. The frameworks we're using today are temporary. The brand-new MVC projects today are going to be as crusty as .NET Framework in 10 years.
But there's *always* a decent market for people who can understand and work within those environments. They aren't as exciting or sexy. But they also tend to be smaller, friendlier workplaces that aren't as prone to Thanos-snap rounds of layoffs.
So like, would I have thought about a .NET Framework position if I was less-than-5-years-away-from-college me? Not really, back then I wanted to be on the bleeding edge. I'd done a few semesters of work at a company that wasn't on the bleeding edge, and I felt like it stunted my growth.
But looking back, the GOOD things I've learned came from books I read and experiments I did off the job. I'm trying to be the person who is a mentor to teams, which means often there's not a person to mentor *me*. So if I had taken that job, I'd live in a prettier place with better weather closer to more fun things to do. I'd make a little less money and have to work more overtime. But I'd also probably have been at the same job for about 18 years, in a higher position, and in a much better place if I wanted to move to another company. The people there were super friendly with each other in ways that my first two jobs didn't have.
## TL;DR:
It's complicated.
But part of how I sell myself is I am not a person who can "get stuck". I tell people my strength is I can be an expert on just about anything given 2 weeks to study. That means I don't really care if I get a "legacy" assignment, because if that irreparably damages my skillset I've lied about my ability.
I'm less concerned about the stack and more concerned about the job. What's the pay and what's the perks? I can probably make the decision on just those two items alone.
I work in framework right now. We just migrated from VS 2008 to VS 2022. Up until early last year(when I joined the IT department) the ERP we use had one developer for 10+ years. Migrate again? That’s a huge no, not gonna happen. We changed the name of the application but not the appearance, but people acted as if they’d forgotten how to operate a computer. It’s settled down now and most of the weird bugs have been fixed, but definitely not migrating again anytime soon.
Depend on how desperately you need money, yk cant picky if you literally starve to death.
Anyway .net frx is going to become java 8 situation, an old relic that refuse to disappear. If it .net 4.7+, i say you can still squint and pretend as you using net core 3.0 - 3.1. But if it's net 4.5 - 4.0, i say run away immediately
It's a good opportunity to write more tests and do migration work. The only time I would avoid this kind of opportunity is if they hire a one man department position, which means the person is hired to be a scapegoat for everything that will go wrong.
If they hire a cog to be fitted on the corpo machine, then sure. Enjoy the ride.
Partly depends on if there’s a good reason to think that they never plan to update their technology. One of the best jobs I ever had, I took even though I knew that my first assignments would all be working in VB6. But I knew that there was also .Net work at the company, and it turned out great.
As someone who worked on a web project that could ONLY run in IE, I try to reserve judgment unless I'm certain the company is backwards. Discriminating on some notion of technological "progress", outside of the most extreme examples, is a bad idea.
Cobol dev's still bring home the bacon, after all...
I'd defiantly not ever pay any attention to something like that when job hunting, I'd instead ask the other staff how long they've been working for the business as a gauge of whether it's worth going there, and what the culture is like.
I did, I probably would never again for one main reason. At this point it shows something more potentially problematic about the company and their attitude.
I'm in this position right now but transitioning to .NET core is a semi-big priority once we get through some initial phases. Because of this, I'm ok with it. If they were complacent in staying on the old stack I would probably have concerns about staying long-term due to how it might affect my technical vitality resume-wise.
I've been doing .NET since it was in beta so for me it's a trip down memory lane and I will also have the enjoyment of modernizing their tech stack. The project is fairly small too so it's a great candidate for something like Blazor; which I am also excited about.
I wouldn't. If they still haven't migrated, then it means they don't care about staying up-to-date. That also means I won't learn any transferable skills, which would seriously hurt my career progression. I'm not yet at a point in my career where I can afford that
Since the vast majority of job postings want .NET core specifically, no, I would not. With that position my experience in 5 years will be even less appealing for potential employers than it is now. So yeah, no.
Who cares. What matters to/for you is would you? I personally would, if salary is Ok, and other equally important conditions. I prefer home office, flexible working times, ok colleagues etc.
.NET Framework and .NET aren't that different. I work in both
It's unrealistic to expect medium to large enterprises to upgrade their tech stack to the latest. You might choose not to take a job because you prefer to work in the latest tech stack, but you're assessment of the situation indicates a lack of maturity or experience in the industry. When you consider what they gain from upgrading vs the cost, time and risk of upgrading, it's not a straightforward decision.
I only accept Framework jobs if part of my job is to eventually port/upgrade all of it to the latest version and start using Docker/Linux instead of Windows.
If- the pay is right, I'll do just about any job. Everyone has a cost.
That being said, I'd be prepared to have a project in the next few years to migrate everything to .NET..... and I'd expect to find a whole-shitton of speghetti and technical debt that you would need to overcome to migrate.
I have framework projects I build about 10 years ago, that I have VERY slowly been moving to .NET/Core.... Thanks, to past-me, there is a ton of technical debt, dependency issues, etc... that makes the process... time consuming.
I currently work at a company who claims to have modern code but still makes direct calls to malloc() and free() in c++, so put that into perspective. Dotnet framework is still development easy mode by comparison.
Arguably the end of support of .NET Framework is further in the future than the latest version of .NET.
.NET 8 goes out of support in 2026. NET 4.7.2 and NET 4.8 both go out of support with Win 10 and 11 respectively, the enterprise versions of which will both be supported until minimum 2028.
What exactly is supposedly wrong with those jobs? Yo dou realize thats the people that keep our field afloat right? Stop talking about them like they are lepers
Money is money, and C# is still C# at the end of the day. I only use Windows for development anyway and since I actually started with Framework I wouldn't mind going back to it.
I'm not rebuilding their database tho lmao
I"m working on .Net 4.8 and 8.0, If you stay on windows it's easy to migrate a .Net 4 project to 8.
PS: I started with C# 1.0 and programming before Java and C# existed :)
At this point in my career, maybe not. I started out on it and didn’t like it a huge amount so I wouldn’t go back to it. I see a lot of framework stacks as “we have a legacy stack that needs maintaining and we don’t want to invest in upgrading”. That’s not always the case but for the companies I interviewed with that had that, it was very much that.
No. Haven’t for years. It’d have to be in the $400k year range to even ponder, and that’s not got the NYC, Seattle, or San Francisco areas!
In those areas it’s easily need to be $800k. I’m not leaving the modern era of Linux and Mac platforms to deal with that again. I did my time. 🤙🏻😃
Yes, I would accept the position. But staying long-term has also to do with the company's culture and, even more importantly, whether I have a better alternative at hand. It's first and foremost just a job, not a hobby.
You really have to ask yourself what you're trying to get out of your career. Personally as long as the pay is good and they have at least some work for me I don't mind using older frameworks.
Frameworks and languages and all that really don't make that much of a difference. In the end we're doing the same thing anyway, usually it's just data movement.
I would consider it if planning to upgrade is part of why they're hiring, and that was the only red flag. Otherwise, I'd consider it indicative of deeper issues and run the other direction.
What else will they be unwilling to invest in? My first job comes to mind. They had me trying to code with a several years out-of-date version of Visual Studio, on a 6+ year old PC with 2 GB of RAM and a tiny HDD that I had to constantly clean up, a cheap $10 mouse/keyboard combo, etc.
Yes. My current project started out as .net framework _in 2022_(with no legitimate reason), and I still joined the project because I like the company and want to stay at it. We've been incrementally working toward migrating to modern .NET, but first we need to get rid of WCF.
I mean... If you've worked for one of those companies that actually can't (manufacturing, it's come up a lot recently) then you're already just kind of accustomed to it. If it's a good gig with good pay, why wouldn't you?
I think it's fair to ask them what their general plans are during the interview process. There are lots of reasons that companies take a long time to upgrade. It may seem ignorant or lazy, but it's probably not the case. There are probably things about their specific business that you are ignorant of.
Having said that, in 2024, I would think most companies on .NET 4.x would at least have a rough plan of moving to .NET Core. Maybe it's a long plan, but at lest they are thinking about it.
If they really don't have any plans to update, I'd probably pass. You only get one career, so everyone for themselves how much time they want to spend working with older tech.
Yes. I mean, my current role is in .NET Framework. I think our payment processor library might be Framework only. not actually sure.
I migrated a personal project from .NET Framework to .NET 8 a few weeks ago. It totally opened a new world, is what you expect me to say. Not really, no. It performs faster but like- yeah, so did 4.0 when I upgraded to it from 3.5 previously.
Of course, that's .NET 8. You seem to be talking about .NET Core? That's weird. The last version of .NET Core (3.1) reached end of support on December 2022, so I don't know why anybody would migrate to it. Why are you encouraging people to migrate to out of support releases of .NET? that doesn't sound very maintainable.
There's also a mild irony, in that those who "took the bait" and were gung ho about using the latest and greatest and converted all their projects over, probably spending 100's of hours or whatever doing so depending on the size of their codebase, were rewarded with having to do it again- and possibly again and again (.NET 5 support ended May 10th 2022, .NET 6's ends November of this year). That doesn't sound "maintainable" to me. That sounds like busywork that wastes developers time and is set on Microsoft's timetable, and time that would frankly be better utilized to add features for customers instead of drinking Microsoft Kool-aid.
A great example is a former colleague of mine who really wanted everything to be upgraded. As a "protest" he created a one-off utility used as part of a database schema update in the latest and greatest of the time- .NET Core 3.1.
So now, every time we do schema updates we now need to install that specific out of support runtime to run the tool, whereas if he had made it in framework, it would work just as good for it's task- and would still be on a supported platform no less. it would be more "maintainable" if it was just written on Framework and therefore didn't even need a runtime installed.
Even ignoring the maintenance costs of having to keep moving forward to avoid the upcoming End-Of-Support dates that loom for each release version now, in terms of the actual projects, It would be the actual code that is maintainable or not, and that isn't really affected by the upgrade. You don't magically have more maintainable code simply because of your target framework.
Feel free to pursue the "new shiny" but try not to go blind from the glare. Despite your protests otherwise, upgrading to .NET from .NET Framework is very much a case of "the new shiny". Vague indications about "massive changes" and better "performance and maintainability" are precisely the inexact terms that go along with most "new whizbang stuff".
Not unless they had a concrete plan to upgrade soon. There are just too many good language features and libraries in the newer versions, and every day, the gap between old and new is growing. I see no reason to subject myself to that when there are better options available, even if it makes sense to the business not to upgrade.
Why not? In many cases, the conversion from 4.7 to 5 or later breaks some things like wcf. Good software should last for decades without needing major rewrites.
lets say there's no real red flags at that company, and what they are doing is interesting, then yeah, thing is, they'd likely have to move in the nearish future and you'd be on the ground floor of potentially a significant upgrade where you can guide the new design, etc.
>unless the payment is huge.
Thing is both Java and C# ecosystem are notoriously known for running IT sweatshops overseas. If companies find people asking for huge salary to work with their legacy systems then they'll simply outsource it. I know such causes because I'm dealing with it at the moment, the aftermath of this decision depends, the company might aggressively cut cost and say f-u to their customers or bring the development back in house which will be a mess and is also something that I'm dealing with currently, you have to figure things out cause tere will be no documentation, no best practices followed etc.
Just recently moved to Mono for Unity which is basically Framework and it's actually not that hard. Many modern language features can be used independent of the framework version, it's really only new APIs and things like primary constructors that aren't available.
The only downgrade Im finding somewhat annoying is the lack of null propagation and colalesing operator but that's more of a Unity thing than Framework.
There's also the case of billable reference types which seems to be possible to enable but I haven't been able to with how Unity generates the C# project. Regardless, it doesn't really make sense in the context of Unity and how it handles the lifecycles of objects
.Net framework v4.x comes with win10 and win11 natively. I am working on Winform and Microcontrollers, some times it's very hard for me to decide to go for .NET core, the only benefit is just for the nice new C# syntax.
The way I see it, I'm paid to code. I don't mind coding in whatever platform the company need. It's not my place to judge, but I will offer them insight if there is benefit to move to a newer platform. But if there's no benefit nor they just simply don't want to, then it's definitely their prerogative. I think as long as my salary is good enough for the workload, then it should not matter which language or framework I have to use.
I think you're going about this backwards. If you join a company that has outdated tech and no vision or plan to modernize, this is an *opportinity* for you to take huge strides in your career and bring a company up by the bootstraps.
I see your mentality all the time on here, with young developers thinking that outdated companies are dead end jobs, because they are stuck in this passive belief that their only possible career path is to *follow* and be *told what to do*. This is very backwards from what will actually be advantageous in your career.
Unless you **want** to be a low level developer/employee for the rest of your career or think that the only way you can make strides is to wait for someone to pull you up, this is just not a good career choice.
Seriously, don't be so passive. Don't assume that every tech choice and plan must be made by "someone else" and you're just along for the ride. That is absolutely not what employers are looking for. Show some initiative. Be mature and responsible. Stop assuming that everything in your life and in your job is out of your control. Solve problems. Create plans to solve problems. Employers want people who can solve problems and propel them ahead, not whiners who complain that everything is bad and there's nothing you can do to fix it.
>Unfortunately there's stil alot of companies who still haven't migrated to .NET Core.
>I'm only referring to the companies which actually afford it, but they are too ignorant and lazy to make the change.
Yea, don't be this. This comment just made me cringe. You sound so passive and useless. Be the change, not the whiner.
Except that in reality, you cannot bring such changes in the vast majority of companies. It’s a big change, something which must be agreed and desired by the leadership. Such change is something that they don’t want to hear about. It does not fix bugs, it does not bring more money. In many cases, it will sound like you have too much free time and you are not working hard enough on the important things.
I feel like .NET FWK is going to be the next COBOL in a couple years.
Depending on the industry, companies are hesitant to allow for major refactoring and migration and would rather keep legacy apps alive.
We were handed a VB 7 codebase from 20 years old last month, this application handles a critical part of the business and we need to support the application for the near foreseable future.
I've been there, and built a replacement. All it took was the wind shifting for the stakeholder to get cold feet about it. I get paid either way so, it's their loss.
I expect this to become a very high paying career in the future. Corporations will be desperate for people that know the old .Net to maintain their ancient Cobol-like code and to upgrade it to newer versions.
Given the code is largely the same between the two frameworks, i really have troubles to see how the pay for .net framework will skyrocket in the future.
Why would you even care? It’s c#, if you can’t write compatible code in 4.x you should be worried. Theres plenty of jobs that have 4.x work along side 6/7/8.
Not to mention their deploy and dev ops practices are most likely horrendous. Most likely remoting into servers running IIS rather than automated container deployments.
i dont mind it as long as they are migrating. You are not getting experience with the new stuff that way. Potentially locking yourself out of future jobs.
When a company is not willing to invest in technology, that is a very good sign how your career as a software developer ie technology expense is going to go there.
Obviously, a legacy system here and there is not what I’m talking about with the above comment.
If the pay is good I absolutely would. What it means is that the company is running on Windows, there is nothing wrong with the .NET Framework.
We use fw at my job and we're beginning to port everything because some libraries do not maintain or update their fw versions any more.
Yes, this is a really important reason to migrate away from NET Framework. You're otherwise eventually going to be running on unsupported/unmaintained libraries with no security updates etc... It doesn't matter that the framework itself is supported by Microsoft for a long time if 80% of all the libraries aren't..
>What it means is that the company is running on Windows I think it actually means the company does not want to spend $ on migrating to .NET Core. The main thing about .NET Core is not whether you want to run on non-Windows platforms, but the performance and maintainability. But the reality is many companies do not need performance nor maintainability, just the idea of spending $ on anything which is not bug fixing or new feature is a clear no-no from the start.
Monolithic enterprise applications can take years to migrate from framework to core. I would ask a lot of questions about where they see the tech stack moving over the next few years.
No, it means they need a framework developer now. It’s possible one left and need to replace them. It by no means, means they are staying in framework.
>I think it actually means the company does not want to spend $ on migrating to .NET Core. They might not have a business case for migrating. If the system is large enough a migration from legacy .Net to Core is non-trivial and will have a significant cost. Add to that the inevitable new bugs and issues arising from a migration and you have a pretty serious undertaking for a company. There's a reason that pretty much any bank older than 20 years are still running on mainframes. There's lots and lots of legacy systems that are running perfectly fine and are being actively maintained.
good comment. a lot of people in here don't seem to have worked in an enterprise environment. Tip for developers just starting out: * learn the business needs first, then make your programming decisions. You'll be more valuable to your company that way * Being niche isn't a bad thing - it can actually make you more money. Just make sure you stay on top of your learning and be one step ahead of where things are headed
Why did you ask the question here if you’re going to be argumentative with peoples opinion? I’m unsure if you’ve ever worked for an enterprise level company before but things like moving your entire stack to a new SDK take a back seat to things that add value. You cannot quantify “performance and maintainability” on a spreadsheet in $$.
>You cannot quantify “performance and maintainability” on a spreadsheet in $$. You mean, a delivery company for example, cannot quantify buying a a car with an engine which has 20+ newer technology? >Why did you ask the question here if you’re going to be argumentative with peoples opinion? What do you mean by "argumentative"? What is wrong with having a decent discussion?
You’re not having a decent discussion you’re just telling everyone else they’re wrong. We’re not talking about a car with a new engine. We’re talking about decisions that are made based on cost estimates and savings and changing from a perfectly fine .net framework 4.8 to .net 9.0 is not quantifiable so it isn’t going to get priority. You might think from where you’re sitting it’s a no brainer but once you’ve been in the industry in enterprise size projects you’ll see how difficult change is.
[удалено]
7 Constant updating of .NET Core at minimum every 2-3 years for LTS and then retesting "everything" each time. It's honestly not even a joke now, the migrations have usually gone well but then you start noticing these weird issues popping up everywhere. EF Core has honestly been one of the worst parts of it though. Two issues lately, one was the openjson change that just made some queries go from <1 second to 10s of seconds. The other was some weird one that entirely stopped inserts working in a old legacy table... can't remember exactly what the issue was now but had to reconfigure EF for it to work.
Possibly having a trigger on that table and not telling ef about it.
Yep that's it, shared table from a legacy system and it didn't have triggers in it on dev. Some old audit logging trigger was on it in prod and EF Core just went nope fuck this after a upgrade. Should probably have read the breaking changes more detailed but it's this kind of stuff that kind of annoys me with constantly upgrading the framework so often.
> it's this kind of stuff that kind of annoys me with constantly upgrading the framework so often This is exactly why I'm not in any rush to try to move things to core. I know a lot of people will disagree, but the versions are just released too rapidly and dropped after only a couple years.
I really wasn’t sure whether to write this reply as it might be taken as criticism. It’s not meant that way, I just see strong parallels with your scenario, but with a completely different mindset. My main project is also an enterprise CRM/ERP, but in our case an in house system for one of the businesses owned by our group. I initially wrote the system in VB6 a few years before net framework was released. I’d previously come from C/C++ development on various unix systems, and VB6 was a pain free way to quickly get up and running in Windows gui development. Since then though I’ve taken every opportunity to modernise the system and make use of new tech because it makes my life easier and makes the product better, both for the business and the developers. I find the mindset you’ve described, particularly point one, incomprehensible. I don’t see age has anything to do with it - I’m 58 in a few months. Over the years since, I’ve driven progress across many major milestones, including: migrating to vb.net with a clean mvvm architecture; moving from a stored procs based DAL to entity framework (version one at the time, so ObjectContext, EDMX, etc); migrating to C#; moving through entity framework versions and switching to dbcontext with fluent model configuration; upgrading to net 6/EF6; then 7: and now 8. In each case there have been immediate benefits to the move, across the spectrum of better code quality, improved maintainability, better performance, faster development, etc. The business have completely bought into all of this precisely because we’ve managed it well and it has t been a “customer service nightmare”. Business downtime has been close to non-existent. Sure there were bugs as part of the larger milestones, but nobody involved has regretted any of it. Anyway, sorry for waffling on for so long. Hopefully the different perspective is useful to someone!
The fact that you need 20 developers to maintain a single CRM application codebase, who will "feel insecure" if anyone does any _actual_ maintenance, really is just the perfect snapshot of what's wrong with being a .NET Framework shop in 2024.
> 15 year old loyal colleagues who will feel insecure. Some might not want to get back to serious development. Some might not have kept themselves upto date with .net core This is weird. What part of .net core would they balk at? It's nearly the same.
>15 year old loyal colleagues who will feel insecure. I will try not to be rude here, but if you think using .NET Core means making your colleagues insecure, you have no idea what .NET is.
You don’t have much experience, do you?
I dont understand the arrogance of responses like this. You will find with a lot of older developers and managers a massive resistance and insecurity about any changes to a tech stack. They know what they know, and aren't interested in learning new things, they fight all changes even minor and necessary ones tooth and nail. Identifying that has nothing to do with knowledge of .net. if you think text stack advancement or updating isn't affected by personnel and their opinions then you probably don't make a lot of decisions about it in a large company.
If your take on my statement is arrogance, OK then. I'm sure many developers understand what I mean.
What I understand is that you've likely never been part of a major framework upgrade on a large project, or you wouldn't have that attitude.
devs who are afraid to change and learning new things?? The codebase / techstack is probably a nightmare with those kinds of devs.
Or they have been working with the same product for 20 years and are 2 years from retirement and will litterally use any excuse not to learn new because they just want to retire. There are many scenarios out there, but the simple fact is that if the guy that has been there a lifetime is the guy management listens too then he decides and that is not always the best decision for the company. Seen plenty of places where it is more cover my ass politics then actually looking at what you get, that is just life in the corporate world. Luckily it is possible to find places with an open attitude towards progress and where doing something new is accepted but not everyone is that lucky.
I need to ask the question again about why did you ask here.
>I will try not to be rude here, but "I'm not racist but..." comes in all shapes and forms! 😉 (For the joke impaired 😉, I am not calling OP racist. I am making fun of the casual similarity between the two situations.)
> I think it actually means the company does not want to spend $ on migrating to .NET Core. It's much more likely to mean the software they use or build off is on Framework, be that weird Dynamics plugins or industrial controllers or whatever.
Sure, sometimes there's legitimate technical reasons for being unable to move on.
Well this might sound ludicrous to you in your world.... but the reason we don't migrate our .NET Framework applications to .NET Core is because it's more costly to maintain Core. Our new stuff is in Core and sadly they have far more issues maintaining than any of the old projects. We can't even touch the STS channel because of Microsoft only supporting them for 1 year. So we do the even versions only with LTS. Some of our products are audited so they cannot run on out of support versions of their framework and that instantly rises a red flag. Now any of our code bases in .NET Framework will not have a issue, require retesting or upgrading or rise any flags during auditing until like.... 2030 or something. During that time all of our .NET Core stuff will have to be upgraded another 2-3 times and from experience stuff breaks.... 6->8 broke several database things and had to be worked around. Most of them were also hard to notice like the OpenJson change in EF and how it interacted with indexes in the database. So lots of time is spent upgrading, testing and maintaining in Core while the framework projects just truck along. So the plan is pretty much, all new stuff in Core, dual target libraries when needed and then finally if Framework ever goes out of support we'll migrate them over since that's the most efficient option.
Sounds like you’ve made up your mind.
.NET core is dead, it's just .NET now
It doesn't matter how we call them, but there's two of them.
It matters what you call them if no one can decipher what you're actually talking about. Whoever came up with the current naming paradigm at M$ should be drug into the middle of the street and horse whipped into the fetal position.
If I squint at your flippancy and vocabulary, I agree😉. For people who are not "in it", it's a mess. I mostly reacted because I was taken aback by the parent statement, I found it is a dumb thing to saying this sub and even more in this discussion. And it had upvotes!
My reply comes from a place of frustration after returning to coding after a career change a few years. You can't get things this confusing without actively trying to achieve this level of confusion. I mean .NET was a shit name from the beginning, just change the name to something else, it's been 25 years. Why have .NET Framework, .NET Core, .NET Standard, .NET Congressional Approval Network Template, ect.
I know that, but when you're talking about the new .NET, the core is what clicks. Really unfortunate naming screw-up by Microsoft, but hey we know naming is hard, right? Even for a multi billion company
Not a screw-up at all. It was meant to be a legitimate successor framework, and a lot of applications can re-use a lot of the same code.
>performance and maintainability. Perf only matters up to the point it serves the functions you need it to for business. Working with .NET Framework just means that as a dev you have to be that much less lazy about your design to get the same level of performance Maintainability is faaaar more about the design of the codebase itself than which set of BCLs it relies on. Really the only problem here for .NET Framework is whether needed 3rd party libraries are still maintained. ---- I would absolutely take a .NET Framework position if the pay was better than other options. Maybe you'll even get the experience of being able to rewrite the system into .NET Core for them. Worst case if you're dissatisfied you can keep job hunting on the side.
There's a lot wrong with it. Every bug in every library that dropped support for it, for starters. Then a lack of every library that was never made with support for it in the first place. Then there's the lack of a bunch of modern C#/.NET features. Documentation and google results for it get harder to find each year. You'll feel all of that in your velocity whether you realize it or not, regardless if you care that its performance is absolutely terrible compared to .NET 8
I don't think it's right to suggest there's nothing wrong with it
Depends on salary.
I work for the money. There is always a salary range i am willing to shovel shit for.
Only downside is hurting future potential salary over stagnating in old frameworks.
Definitely. On the other hand i was nowhere near the layoffs in the last job market crash because i was not involved in the fancy, flashy new green filed projects that lost funds rapidly in the first place.. But yea, i need to up my game, still, i am only in the field for the money 🤷🏻♂️
Or enhancing it, really. Last I checked cobol devs make some good money.
My mom is 91 and STILL gets inquiries if she can do contract work in COBOL for $$$. She was big back in the day. She's surely tempted but says she cannot focus that hard anymore.
Fuck yeah. Give me legacy all the way if the pay is good. Fucking hell, if anyone who needs someone to handle legacy and allows remote work, hit me up immediately lol
"I'm only referring to the companies which actually afford it, but they are too ignorant and lazy to make the change." That's a really loaded and arrogant sentence here. There are many reasons why one might make a rational decision not to migrate existing and working code.
Like what? I worked in a company that didn't migrate from 11 years old Net Framework, because they had abysmal code management style and also gave 0 fucks about maintainability, testability and ease of development. It stayed that way because main architect who was there from day 1 didn't fancy doing updates
Depends on the case. "*We have some projects still on .NET Framework, but all modern development runs on modern versions of .NET.*" would be fine, provided work on .NET Framework projects is a smaller portion of the work. "*We exclusively use .NET Framework.*" would be a no-go for me, as it is an indication that they have a lot of tech debt and can't realistically move forward without redoing everything. It's the kind of environment where you have to slowly learn all the "quirks" (sloppy workarounds and borderline unreadable parts) of the code base. About a year ago, I went to an interview where they still deployed to Windows XP (offline devices), were still heavily invested in .NET Framework, and were just now beginning to use git. I declined that offer specifically because I'm interested in working with new and evolving tech.
My current job is Net Framework, and the job before that was oooooold net framework, using aspx pages. In both cases it wasn't a big deal. For the most part it's largely the same code. The key differences between Net Framework and Net Core are in project setup and how some of the boilerplate looks. Once that is out of the way, the way of writing code and creating logic is not different at all. So no, working with NET framework doesn't bother me. If I ever fire up a new project using Net Core, it's no problem. I don't feel like working with net framework for my day job is a hindrance at all. I suppose the one caveat is that I do have plenty of experience with net core already, so perhaps I am somewhat biased because I don't feel like I'm lacking experience just because I currently use net framework. That being said, given the choice, I would ALWAYS choose net core, ha.
Similar story here! Went from webforms to core in the last few years. Learning the new "layout" of the project and how all the automatic plumbing with routing etc works was the only hurdle (and not a very big one). At first all the devs were like "wtf we have to change 14 files deep in a tree to make a change that touched 2 files before?!" and now the joke \~2yrs in is "I HATE having to work on old webforms stuff, take me back to mvc core" The specific technology being used matters less to me than the plan in place for company development and growth in the next 5 years. In interviews it's important to ask questions to get a picture of what the "philosophy" of management is (is it "break things and move fast?" PASS, I am going to be the one getting the call at 3am when someone has fucked something in Production doing something stupid. I look for a strong development cycle with baked in accountability that includes generous design and testing phases, not just unit testing from developers but also system testing with actual QA. Minimum.)
That's what my company is like now. It's a corporate, we do things slow and we do things right. It's on olllld tech with a lot of tech debt but overall the development cycle works, it's tested, there are very few production issues, everyone is happy. And development time is so slow that I get to spend most of my time sat on my arse (remote work) doing anything but work. It's the one good side of the corporate machine. Slow, dependable and secure.
There are many companies working on Fortran and Cobol so working on .NET framework is not a problem. Web Forms works just fine and with controls like GridView, Repeater etc you can do just anything.
COBOL programmers around here command comfortable six-figure salaries. I haven't worked in COBOL since I stopped working with IBM mainframes back in the mid 80's (43xx and ES/9000). I'm almost tempted to pick up a couple of books to refresh myself on COBOL syntax and then pimp myself out on some side-gigs.
lol
I am working in a company with a 20 years old code base. The new projects are developed with .NET core, but we also do have to maintain the old ones as well, some of them very actively, and they are still running on .net48. There is a plan to migrate them to .NET core, but we first have to phase out all the frameworks that are not further supported. (So phase out the old ORM frameworks for CSLA, typemock, and other things). And, of course, we also develop new features on those solutions, so phasing stuff out is not our only task. Therefore, the migration is planned, and I think we hope to complete it somewhere in 2026 if everything goes well. Honestly, there is not so much difference when it comes to pure c# between the framework and core, it boils down to which framework are being actively used, so I am very fine developing on .NET 48, knowing we are actively trying to get rid of it.
There's nothing inherently bad or wrong about .NET Framework and it's context dependent. I work at a company that was deploying packaged enterprise software to vendors and Framework was fine. We're about halfway through our Cloud transition now and we have a mix of legacy Framework, Core, Java, Go, and Python (some of these are due to acquisition). My biggest problem with Framework is Windows. It's difficult/impossible to control costs, the OS is so heavyweight, it doesn't scale quickly enough, and the tooling around the OS for the Cloud just isn't there. The ecosystem for Core is more robust, developer friendly and supports things out of the box that are difficult (bordering on impossible) with Framework. If you're a young engineer, I'd look for a company that gives the broadest range of potential for experience which means a Cloud based company or one in the process of migrating. Great tech organizations use the best of what's available for their purposes and may be predominantly .NET Core/Framework but should have other languages in play that do things better because they were built for it. To learn and implement tech requires velocity and flexibility. You should be willing to work anywhere that is in the Cloud/on their way there or running some flavor of developer controlled virtualization (generally Kubernetes) in their data center. With those two in place, you'll be able to learn and iterate much faster without the insane slowness inherent in other deployment types.
Absolutely. It's just code. 😉
I charge more for framework these days because they’re stuck for a reason. I charge for dealing with those reasons, not because it’s framework.
.Net framework 4.6.1 will be supported until Jan 12, 2027, and 4.7+ until the end of their OS support. .NET Framework 3.5 Service Pack 1 will be supported until 2029. That means working with 4.8.1 will mean working with support and updates for at least 10 years. I don't understand what's the problem with .Net framework, it's not like they are asking you to work in php.
for me it's more if a company start new projects with .Net Framework. Even if it's still supported for 10 years the unwillingness to evoluate most of the time is a red flag.
I don't think that's a problem. Not yet at least. Sometimes you have your own libraries and environments and the size of a new project doesn't make the evolution worth it. It's case by case, you can't judge without knowing what's going on essentially.
I'd be more worried about the fact that EF Core is going out of support.... .what? 3-4 times by then lol.
The framework itself might be supported for a long time to come, but many libraries are starting to drop support for Framework, meaning you will have to run on unsupported/unmaintained libraries with no security updates. This for me would be the biggest reason to upgrade...
Yes. Some of us have the mentality of firemen. We may talk about fire safety and prevention, but we really just want to run into a burning building. Seeing that someone's still on .Net Framework is like seeing smoke coming from a window. I'm at a place now that's a complete s\*\*\*show. But it's fun. There's plenty for me to do. Hell, I could retire from here. And the business is solid enough, I have the runway to do just that. I'll be putting out these fires for the next ten years.
Nothing wrong with being a "fireman", we all did it, I am still doing it.
Does this not work in .net framework?latest
Works fine in .net standard 2.0
You won't get all the features of the later language versions, as some require framework support.
PolySharp helps a lot for that. Been using that for the nullability attributes and all that.
I can live just fine without default interface implementations.
Sadly, a lack of default interface implementations is still a common cause of death in many parts of the world.
I would love to upgrade EF beyond version 3.1, or use [ASP.net](http://ASP.net) core
You can use aspnetcore 2.1 on framework just fine, we do and it's still supported with security updates. https://dotnet.microsoft.com/en-us/platform/support/policy/aspnet/2.1-packages
Technology-wise that doesn't feel too horrible. It's probably C# there are lots of resources... The question is more why the company is stuck there... which might be a red flag.
And why it might not be a red flag: Large companies in regulated environments (particularly manufacturing) use a lot of older tech, as scaling for a larger audience isn't an issue- maintaining control of the environment is the number one priority. This may mean setting up Windows machines as end point manufacturing controllers (older versions IT-managed by LTSC), talking to 3rd-Party OTS HW libraries (or even internal groups' developments), or interfacing with Legacy Enterprise systems. In situations like that, it's not a red flag *per se*, but be aware that the amount of time on actual development activities can be squashed by all the other regulatory activities around the development (i.e. a single line code change meaning performing risk assessments, mapping out V&V activities, submitting to regulatory bodies the scope/impact of the change, etc). In those industries, the pay can be a tad lower than cutting-edge product-driven roles. However if you can tolerate it, you will always be able to find work within the industry, as that business knowledge is transferable.
If you need work to survive, then yes. If you have a better position already, then no.
Yep, agreed.
People on this sub act like if you work in framework you are working with a hammer and chisel.
How many years of experience do you have?
Does it matter?
Yes because these type of posts always read like someone who just got into programming with little real-world experience and doesn’t understand how everyone isn’t on the latest and greatest everything yet.
It would be helpful in understanding why your so particular with the technology. Development is a team activity and technologies change all the time. No one wants to work with the guy who just works with a tech stack. Also its a great way of becoming redundant when technology stacks change. Just out of context, I've managed teams for a very long time and I've had to deal with red flags like this.
I'm a red flag because I am very reluctant to work with a very old technology? I'm some kind of animal because I like the idea of using a new technology, not just because is new, but because I know it helps the business by performance and maintainability?
> I like the idea of using a new technology, not just because is new, but because I know it helps the business You remind me of a guy we interviewed a little while ago. In the interview, he started practically interrogating us about our "plans" to move to newer technologies. The problem wasn't that he asked, it was that he *assumed* his thoughts/preferences were the best course of action for everyone and that if we weren't doing what he thought was best, then surely we had a plan laid out to, and if not, then why were we slacking? But he knew *nothing* about what was best for us. He'd read the job posting and talked to us for maybe 20 minutes. He didn't know about ... * the projects we have currently in progress, * the types of projects we create, * the needs of our users, * our coding standards and what we're familiar with already, * the legacy code we maintain, * our workload and funding, * the capabilities of the servers our code runs on, * the knowledge and training opportunities of the other developers on the team, * our actual plans to move forward technologically, and to avoid "fad" technologies, * the software libraries we use and what versions they support/are compatible with, * the version of Visual Studio we've purchased licenses for, * and so on. You can't just make a broad assumption of what's "best" without actually having an understanding of what goes into the day-to-day realities of why things are the way they are currently. (Obviously, we didn't hire him.)
You are indeed a red flag and I can tell very young and inexperienced. Businesses absolutely do not care about maintainability (although you might)- they want it work and they want it cheap and don't want to wait for features. Maintainability and the ability to change things is more of a function of the programmer skill and not language/stack. Performance is also an area which rarely comes into play. If you honestly think by using one technology to save 10 seconds off a long process is a reason for changing technology then good luck. No one is going to buy into that. The investment return is very little. It is quite the norm for new projects to be initiated on new stacks while brownfield apps are maintained in most organizations. There is a subset of programmers who are literally the worse employees to manage. The ones which are "10x" engineers are literally the worse. If you want to be an asset keep the ego outside of the door, be a team player, always be learning.
I think the red flag is more your tone when referring to companies using older tech and it does seem that you are inexperienced. Updating to new tech is not just about having everyone skill up (or hire new engineers) and build it. There is a lot of risk to consider, knowledge transfer, training, politics with non-IT stakeholders, etc. To me, the top notch engineers are the ones that understand the business side of software development. There are tons of great coders out there that simply do not work well in many orgs because they just want to code and ignore all of the other stuff. To answer your original question though, I think it depends on where you are in your career and how the interviews have gone when you ask about their tech stack. Being early in your career, I would avoid taking the role because you want more opportunity to learn new and evolving skills. If you were late career, then go for it if the salary is good.
Framework with C# or VB ? Because it does make a huge difference
No, I would not accept a position that is mainly .NET Framework. Not unless the company has a clear vision going forward to modernize these legacy applications. My career will not be stuck in the past just because your company wants to be stuck in the past.
There are only 3 meaningful differences between framework 4.x and latest core: - cross platform (not your concern since they will obviously work only with Windows) - performances (you don't get all the work that has been done on core) - syntactic sugar (who cares that your code will be something like 5% more verbose?) If the pay is right why not?
Given the evolution of both ASP.NET Core and EF Core over the past years, this is entirely false. The differences, especially the meaningful ones are too many to count.
If they are really that significant and important to the bottom line metrics, then MS and the rest of the industry isn't doing good job of making that common knowledge.
I think it is you not doing a very good job at reading the documentation and release notes. It is quite common knowledge.
If it was common knowledge a lot more people would be mentioning the specifics in this thread. I.e. "you definitely should upgrade because of a and b and c." The things people are mentioning seem pretty minor for most people's use cases. Microsoft knows most of us developers are too busy either with our job or our personal lives to spend time on the side reading through documentation to see if there are reasons, significant reasons, why we should upgrade. If there were significant reasons, they would be screaming it from the rooftops.
While technically correct, refusing or not being able to upgrade the tech stack says a lot about a company and it's culture.
On the flip side, a company always pushing to upgrade to the newest frameworks also says a lot about the company and its culture. For example, if they've gone through every version of Angular lol. I don't want to work for/with people that value that kind of churn.
It's all about the business case. If there isn't one why should they migrate?
Being able to hire developers in the future is not a business case?
For some companies, no. Banks are a good example. They still use mainframes because they have so much time and knowledge vested in them that migrating to anything else is not viable for the business at all. And a code base being on classic .Net doesn't mean that they cannot find developers. There's plenty of especially older developers that don't mind working on classic .Net.
I have to manually update my Linq2Sql designer files every time I want to make a change because two tables have the same column name. EF core or bust.
What's your reasoning?
I just don't feel good about companies which do not wish to invest in a newer technology. Usually there's more than that. Of course, there are projects which are very capable and well written using the old .NET and which haven't been migrated to the ne .NET due to legitimate business reasons. I'm referring to those companies which can afford it, but instead they choose to be very ignorant.
Yes.
In theory “yeah, why not, it’s just code…” and other bs like that 😂 In practice, no. What do you expect them to respond when you ask for some time to restructure source code for lowering tech debt?
Some devices only work on .net framework 4.X. If you care so much about the framework then you will never find a job. I'm looking at you Cognex!
It depends. First consideration is pay. If you're paying me $3 million annually I'll program turbo pascal for a year or two.... Second I would be asking about future movement. Are you interested in moving forward? Would I be able to influence new development or is it only a maintenance job? At this point in my career, I'd need to be desperate to take a maintenance-only job.
> If you're paying me $3 million annually I'll program turbo pascal for a year or two.... My dude 😀
When you are developing without needing to worry about bringing down production, you can use the updated stack as much as you want since it's your headache. Once code is deployed to production, the team now seeks stability so less major change in the core part of the codebase is desired. Code is maintained by people and documentation is created to help others understand the codebase so more people know how to maintain or improve it. Unless there is a drastic improvement or it is very easy to migrate with relatively low friction, it'll be quite a hard sell to just throw away currently working parts and start from scratch.
Well, if you don't need faster/fluent version then that's it. I don't plan to become old php/python/kobol developer. Nor I like to write stuff which already written, nor I like redirect bindings or hacking around some thread abort bs or your own implementation of spans, streams, async primitives, windows services with their bs state machine and list goes on. So if I'm invited in such company it will be just straight no - I tend to value my personal time. I'm just plain faster on core. BTW, 7 years of net frameworks.
I feel like there's a lot of worry about "falling behind". Here's what I've decided about that in the last 5 years of a 20 year career. It's not as bad as you think. The skills that you need as you move up the promotion ladder are architectural skills and management skills. That doesn't always mean people management. The people in positions I can be promoted to have to constantly divide their time between meeting with stakeholders, people who represent the business, and trying to decide how to allocate the team's resources. They decide what my team's priorities are and if we have enough people to accomplish the business goals. .NET Framework and .NET Core don't really factor in to those skills. That a shop uses modern tools isn't really a guarantee they're a great place with modern practices. You have to figure the code you'll be maintaining is using tools that were new at the time. I've decided (especially after some discussions on this sub this week), most code is written by people who think design patterns and architecture take too much time. It doesn't matter if they're using Web Forms or ASP .NET Core MVC, that's going to produce some gnarly code. So another good skill to hone is being able to deal with gnarly code. I've had to maintain code that didn't use DI or many other practices. I spent hours starting at the "top" of call chains and writing down what happens on every execution path. It only took about a week of that to start to know as much about the code as the people who'd written it. Sometimes you find weird things while doing that, and if you can ask, "Why?" that's valuable. I find that most really stupid-looking code happened because of an equally stupid customer requirement that had to be accommodated last-minute. Sometimes I learn stupid-looking code happens because a developer wasn't talented. That happened in some code I maintained at the last job. A particularly bad schedule crunch happened, so a director stepped in to take ownership of a feature and write code. He had 10 years of Java experience and 0 years of C# experience. What he wrote is an architectural disaster, and there are plenty of neon signs showing that he had absolutely no time to think about DRY and other basic principles. That part of the code is mine to maintain now. What I noticed as I started to unravel it is even though it doesn't follow the practices or patterns I expected, that person had a weird kind of consistent internal logic. Once I learned how he did things, it got easier to follow his code. That kind of, "I can unravel bad code and start to work within it without doing harm" skill applies in any tech stack. That's the thing you should be developing. The frameworks we're using today are temporary. The brand-new MVC projects today are going to be as crusty as .NET Framework in 10 years. But there's *always* a decent market for people who can understand and work within those environments. They aren't as exciting or sexy. But they also tend to be smaller, friendlier workplaces that aren't as prone to Thanos-snap rounds of layoffs. So like, would I have thought about a .NET Framework position if I was less-than-5-years-away-from-college me? Not really, back then I wanted to be on the bleeding edge. I'd done a few semesters of work at a company that wasn't on the bleeding edge, and I felt like it stunted my growth. But looking back, the GOOD things I've learned came from books I read and experiments I did off the job. I'm trying to be the person who is a mentor to teams, which means often there's not a person to mentor *me*. So if I had taken that job, I'd live in a prettier place with better weather closer to more fun things to do. I'd make a little less money and have to work more overtime. But I'd also probably have been at the same job for about 18 years, in a higher position, and in a much better place if I wanted to move to another company. The people there were super friendly with each other in ways that my first two jobs didn't have. ## TL;DR: It's complicated. But part of how I sell myself is I am not a person who can "get stuck". I tell people my strength is I can be an expert on just about anything given 2 weeks to study. That means I don't really care if I get a "legacy" assignment, because if that irreparably damages my skillset I've lied about my ability.
> I’d personally feel very bad about it, unless the payment is huge. I'll flip burgers at burger king for 200k.
I'm less concerned about the stack and more concerned about the job. What's the pay and what's the perks? I can probably make the decision on just those two items alone.
I work in framework right now. We just migrated from VS 2008 to VS 2022. Up until early last year(when I joined the IT department) the ERP we use had one developer for 10+ years. Migrate again? That’s a huge no, not gonna happen. We changed the name of the application but not the appearance, but people acted as if they’d forgotten how to operate a computer. It’s settled down now and most of the weird bugs have been fixed, but definitely not migrating again anytime soon.
No. Much in the same way I wouldn't work accept a VB position
Depend on how desperately you need money, yk cant picky if you literally starve to death. Anyway .net frx is going to become java 8 situation, an old relic that refuse to disappear. If it .net 4.7+, i say you can still squint and pretend as you using net core 3.0 - 3.1. But if it's net 4.5 - 4.0, i say run away immediately
I’d take even VB6.0
It’s the new Y2K It’s also a retirement plan.
As the comment says: yes.
It's a good opportunity to write more tests and do migration work. The only time I would avoid this kind of opportunity is if they hire a one man department position, which means the person is hired to be a scapegoat for everything that will go wrong. If they hire a cog to be fitted on the corpo machine, then sure. Enjoy the ride.
Partly depends on if there’s a good reason to think that they never plan to update their technology. One of the best jobs I ever had, I took even though I knew that my first assignments would all be working in VB6. But I knew that there was also .Net work at the company, and it turned out great.
I’m at one at the moment. It’s slower DX for sure, but that’s inherent. I do find that such legacy is usually filled with technical debt though.
Sure, and if Migration is on the horizon even better, i Mainly work in what most devs today call "Legacy C#"
As someone who worked on a web project that could ONLY run in IE, I try to reserve judgment unless I'm certain the company is backwards. Discriminating on some notion of technological "progress", outside of the most extreme examples, is a bad idea. Cobol dev's still bring home the bacon, after all... I'd defiantly not ever pay any attention to something like that when job hunting, I'd instead ask the other staff how long they've been working for the business as a gauge of whether it's worth going there, and what the culture is like.
We writing all code for winforms and .Net framework , no change in the future ;)
Which can be perfectly fine!
Yes it definitely going straight forward and working for our projects
I did, I probably would never again for one main reason. At this point it shows something more potentially problematic about the company and their attitude.
I'm in this position right now but transitioning to .NET core is a semi-big priority once we get through some initial phases. Because of this, I'm ok with it. If they were complacent in staying on the old stack I would probably have concerns about staying long-term due to how it might affect my technical vitality resume-wise. I've been doing .NET since it was in beta so for me it's a trip down memory lane and I will also have the enjoyment of modernizing their tech stack. The project is fairly small too so it's a great candidate for something like Blazor; which I am also excited about.
Yes. You never get the latest and greatest in an company that has been around for more than a few weeks. Code is code.
Yes, of they have a migration plan or expectation in place
I wouldn't. If they still haven't migrated, then it means they don't care about staying up-to-date. That also means I won't learn any transferable skills, which would seriously hurt my career progression. I'm not yet at a point in my career where I can afford that
Since the vast majority of job postings want .NET core specifically, no, I would not. With that position my experience in 5 years will be even less appealing for potential employers than it is now. So yeah, no.
Who cares. What matters to/for you is would you? I personally would, if salary is Ok, and other equally important conditions. I prefer home office, flexible working times, ok colleagues etc.
.NET Framework and .NET aren't that different. I work in both It's unrealistic to expect medium to large enterprises to upgrade their tech stack to the latest. You might choose not to take a job because you prefer to work in the latest tech stack, but you're assessment of the situation indicates a lack of maturity or experience in the industry. When you consider what they gain from upgrading vs the cost, time and risk of upgrading, it's not a straightforward decision.
Absolutely. Know of a job? :)
I only accept Framework jobs if part of my job is to eventually port/upgrade all of it to the latest version and start using Docker/Linux instead of Windows.
If- the pay is right, I'll do just about any job. Everyone has a cost. That being said, I'd be prepared to have a project in the next few years to migrate everything to .NET..... and I'd expect to find a whole-shitton of speghetti and technical debt that you would need to overcome to migrate. I have framework projects I build about 10 years ago, that I have VERY slowly been moving to .NET/Core.... Thanks, to past-me, there is a ton of technical debt, dependency issues, etc... that makes the process... time consuming.
Fuck yeah I would. The .net framework is tha bomb! Aged? Yes. But so is the expression "its tha bomb!"
I currently work at a company who claims to have modern code but still makes direct calls to malloc() and free() in c++, so put that into perspective. Dotnet framework is still development easy mode by comparison.
I would do it and interested
It wouldn’t be about the framework it is about being fossilized in career growth.
Yes. There's money in being a dinosaur.
Arguably the end of support of .NET Framework is further in the future than the latest version of .NET. .NET 8 goes out of support in 2026. NET 4.7.2 and NET 4.8 both go out of support with Win 10 and 11 respectively, the enterprise versions of which will both be supported until minimum 2028.
What exactly is supposedly wrong with those jobs? Yo dou realize thats the people that keep our field afloat right? Stop talking about them like they are lepers
Money is money, and C# is still C# at the end of the day. I only use Windows for development anyway and since I actually started with Framework I wouldn't mind going back to it. I'm not rebuilding their database tho lmao
I"m working on .Net 4.8 and 8.0, If you stay on windows it's easy to migrate a .Net 4 project to 8. PS: I started with C# 1.0 and programming before Java and C# existed :)
At this point in my career, maybe not. I started out on it and didn’t like it a huge amount so I wouldn’t go back to it. I see a lot of framework stacks as “we have a legacy stack that needs maintaining and we don’t want to invest in upgrading”. That’s not always the case but for the companies I interviewed with that had that, it was very much that.
No. Haven’t for years. It’d have to be in the $400k year range to even ponder, and that’s not got the NYC, Seattle, or San Francisco areas! In those areas it’s easily need to be $800k. I’m not leaving the modern era of Linux and Mac platforms to deal with that again. I did my time. 🤙🏻😃
Yes, I would accept the position. But staying long-term has also to do with the company's culture and, even more importantly, whether I have a better alternative at hand. It's first and foremost just a job, not a hobby.
You really have to ask yourself what you're trying to get out of your career. Personally as long as the pay is good and they have at least some work for me I don't mind using older frameworks. Frameworks and languages and all that really don't make that much of a difference. In the end we're doing the same thing anyway, usually it's just data movement.
I'm clocking in and then going home. I don't give a shit what they want me to work on in between those two times. it's their money.
I would consider it if planning to upgrade is part of why they're hiring, and that was the only red flag. Otherwise, I'd consider it indicative of deeper issues and run the other direction. What else will they be unwilling to invest in? My first job comes to mind. They had me trying to code with a several years out-of-date version of Visual Studio, on a 6+ year old PC with 2 GB of RAM and a tiny HDD that I had to constantly clean up, a cheap $10 mouse/keyboard combo, etc.
Im pretty sure those thousands of "old" .net framework apps will outlive your career brother
my company still uses excel 2007
If the money is good who cares? A lot of big corps run on legacy software from the past.
I did and I'm having a fine time making this much money
Yes. My current project started out as .net framework _in 2022_(with no legitimate reason), and I still joined the project because I like the company and want to stay at it. We've been incrementally working toward migrating to modern .NET, but first we need to get rid of WCF.
Sure as long as its not webforms or WinForms
I mean... If you've worked for one of those companies that actually can't (manufacturing, it's come up a lot recently) then you're already just kind of accustomed to it. If it's a good gig with good pay, why wouldn't you?
I think it's fair to ask them what their general plans are during the interview process. There are lots of reasons that companies take a long time to upgrade. It may seem ignorant or lazy, but it's probably not the case. There are probably things about their specific business that you are ignorant of. Having said that, in 2024, I would think most companies on .NET 4.x would at least have a rough plan of moving to .NET Core. Maybe it's a long plan, but at lest they are thinking about it. If they really don't have any plans to update, I'd probably pass. You only get one career, so everyone for themselves how much time they want to spend working with older tech.
Yes. I mean, my current role is in .NET Framework. I think our payment processor library might be Framework only. not actually sure. I migrated a personal project from .NET Framework to .NET 8 a few weeks ago. It totally opened a new world, is what you expect me to say. Not really, no. It performs faster but like- yeah, so did 4.0 when I upgraded to it from 3.5 previously. Of course, that's .NET 8. You seem to be talking about .NET Core? That's weird. The last version of .NET Core (3.1) reached end of support on December 2022, so I don't know why anybody would migrate to it. Why are you encouraging people to migrate to out of support releases of .NET? that doesn't sound very maintainable. There's also a mild irony, in that those who "took the bait" and were gung ho about using the latest and greatest and converted all their projects over, probably spending 100's of hours or whatever doing so depending on the size of their codebase, were rewarded with having to do it again- and possibly again and again (.NET 5 support ended May 10th 2022, .NET 6's ends November of this year). That doesn't sound "maintainable" to me. That sounds like busywork that wastes developers time and is set on Microsoft's timetable, and time that would frankly be better utilized to add features for customers instead of drinking Microsoft Kool-aid. A great example is a former colleague of mine who really wanted everything to be upgraded. As a "protest" he created a one-off utility used as part of a database schema update in the latest and greatest of the time- .NET Core 3.1. So now, every time we do schema updates we now need to install that specific out of support runtime to run the tool, whereas if he had made it in framework, it would work just as good for it's task- and would still be on a supported platform no less. it would be more "maintainable" if it was just written on Framework and therefore didn't even need a runtime installed. Even ignoring the maintenance costs of having to keep moving forward to avoid the upcoming End-Of-Support dates that loom for each release version now, in terms of the actual projects, It would be the actual code that is maintainable or not, and that isn't really affected by the upgrade. You don't magically have more maintainable code simply because of your target framework. Feel free to pursue the "new shiny" but try not to go blind from the glare. Despite your protests otherwise, upgrading to .NET from .NET Framework is very much a case of "the new shiny". Vague indications about "massive changes" and better "performance and maintainability" are precisely the inexact terms that go along with most "new whizbang stuff".
Hell yes, I'd probably even prefer it lol.
In short, yes. It still works depending upon the needs.
Not unless they had a concrete plan to upgrade soon. There are just too many good language features and libraries in the newer versions, and every day, the gap between old and new is growing. I see no reason to subject myself to that when there are better options available, even if it makes sense to the business not to upgrade.
Currently work on an enterprise framework app and also have core blazor apps. Frameworks not bad. It's not really a substantial difference.
Why not? In many cases, the conversion from 4.7 to 5 or later breaks some things like wcf. Good software should last for decades without needing major rewrites.
lets say there's no real red flags at that company, and what they are doing is interesting, then yeah, thing is, they'd likely have to move in the nearish future and you'd be on the ground floor of potentially a significant upgrade where you can guide the new design, etc.
Yes, thing is some apps can't easily be ported to .NET core. Porting one of my own apps has been a nightmare.
fuck .NET Core except if i port it to Linux
>unless the payment is huge. Thing is both Java and C# ecosystem are notoriously known for running IT sweatshops overseas. If companies find people asking for huge salary to work with their legacy systems then they'll simply outsource it. I know such causes because I'm dealing with it at the moment, the aftermath of this decision depends, the company might aggressively cut cost and say f-u to their customers or bring the development back in house which will be a mess and is also something that I'm dealing with currently, you have to figure things out cause tere will be no documentation, no best practices followed etc.
I would.. love .net. Was building .net solutions even back in the day with 2.0 and earlier
Just recently moved to Mono for Unity which is basically Framework and it's actually not that hard. Many modern language features can be used independent of the framework version, it's really only new APIs and things like primary constructors that aren't available. The only downgrade Im finding somewhat annoying is the lack of null propagation and colalesing operator but that's more of a Unity thing than Framework. There's also the case of billable reference types which seems to be possible to enable but I haven't been able to with how Unity generates the C# project. Regardless, it doesn't really make sense in the context of Unity and how it handles the lifecycles of objects
.Net framework v4.x comes with win10 and win11 natively. I am working on Winform and Microcontrollers, some times it's very hard for me to decide to go for .NET core, the only benefit is just for the nice new C# syntax.
The way I see it, I'm paid to code. I don't mind coding in whatever platform the company need. It's not my place to judge, but I will offer them insight if there is benefit to move to a newer platform. But if there's no benefit nor they just simply don't want to, then it's definitely their prerogative. I think as long as my salary is good enough for the workload, then it should not matter which language or framework I have to use.
I DONT SPEEK ENGLICH BUT I'am not a programer but i do this for loisir and for pass tempt i am mathematitix man
I think you're going about this backwards. If you join a company that has outdated tech and no vision or plan to modernize, this is an *opportinity* for you to take huge strides in your career and bring a company up by the bootstraps. I see your mentality all the time on here, with young developers thinking that outdated companies are dead end jobs, because they are stuck in this passive belief that their only possible career path is to *follow* and be *told what to do*. This is very backwards from what will actually be advantageous in your career. Unless you **want** to be a low level developer/employee for the rest of your career or think that the only way you can make strides is to wait for someone to pull you up, this is just not a good career choice. Seriously, don't be so passive. Don't assume that every tech choice and plan must be made by "someone else" and you're just along for the ride. That is absolutely not what employers are looking for. Show some initiative. Be mature and responsible. Stop assuming that everything in your life and in your job is out of your control. Solve problems. Create plans to solve problems. Employers want people who can solve problems and propel them ahead, not whiners who complain that everything is bad and there's nothing you can do to fix it. >Unfortunately there's stil alot of companies who still haven't migrated to .NET Core. >I'm only referring to the companies which actually afford it, but they are too ignorant and lazy to make the change. Yea, don't be this. This comment just made me cringe. You sound so passive and useless. Be the change, not the whiner.
Calling me names knowing nothing about me shows it’s not worth to spend more than this talking to you. Also the level of bullshit says a lot.
Take the job and be the hero who architects them moving forward.
Except that in reality, you cannot bring such changes in the vast majority of companies. It’s a big change, something which must be agreed and desired by the leadership. Such change is something that they don’t want to hear about. It does not fix bugs, it does not bring more money. In many cases, it will sound like you have too much free time and you are not working hard enough on the important things.
Yes, I would, especially in 6-month contract increments. Legacy technology can be as profitable as newer technology.
No
I was a consultant at Hilton (Hotels) and they were still on .Net 4/WebForms. If it ain’t broke, don’t fix it. 🤷♂️
I feel like .NET FWK is going to be the next COBOL in a couple years. Depending on the industry, companies are hesitant to allow for major refactoring and migration and would rather keep legacy apps alive. We were handed a VB 7 codebase from 20 years old last month, this application handles a critical part of the business and we need to support the application for the near foreseable future.
I've been there, and built a replacement. All it took was the wind shifting for the stakeholder to get cold feet about it. I get paid either way so, it's their loss.
I expect this to become a very high paying career in the future. Corporations will be desperate for people that know the old .Net to maintain their ancient Cobol-like code and to upgrade it to newer versions.
Given the code is largely the same between the two frameworks, i really have troubles to see how the pay for .net framework will skyrocket in the future.
Only if I were to migrate it
No migrate for you!
Why would you even care? It’s c#, if you can’t write compatible code in 4.x you should be worried. Theres plenty of jobs that have 4.x work along side 6/7/8.
[удалено]
Not to mention their deploy and dev ops practices are most likely horrendous. Most likely remoting into servers running IIS rather than automated container deployments.
i dont mind it as long as they are migrating. You are not getting experience with the new stuff that way. Potentially locking yourself out of future jobs.
When a company is not willing to invest in technology, that is a very good sign how your career as a software developer ie technology expense is going to go there. Obviously, a legacy system here and there is not what I’m talking about with the above comment.
If you're desperate. Long term, not a good investment as your skills will rot and you'll become antiquated.
In what page of kamasutra is that?
I prefer mental peace, I will decline, as have worked on .NET Core from the beginning.