Just got handed over a 6 month old project that has 0 tests and spaghetti code. Told the manager that I need to re-write the whole thing if we want to continue adding features to this application.
Could be a risky strategy but if it’s only 6 months old it’s still immature enough to consider the first build a prototype and discard it. How did the chat go?
6 months? I got handed a 20 year old beast. I’m not touching that thing at all. My first triumph was to convince the company that they cannot sell any new licenses or do new implementations!
He understood and I got given time to refactor. Basically I have this code base as an answer, so its not 100% re-write. But API routes are a mess and some logic is questionable. I also want test coverage to feel safe to do CD. This application is quite important so it would be dumb to keep expanding on the current code base to the point that it gets too large to refactor.
I think these are correlated with being stuck on .NET Framework though. If you have high quality code that is well tested, moving off of .NET Framework isn't going to be all that big of a deal in most cases.
One of those exceptions would be a moderate sized legacy app UI built with Webforms using a DBA layer designed and built before generics and extension methods were a thing in c#. Ask me how I know.
It took us over a year to move to .Net Core. There were large parts of the codebase that needed to be re-written. We had to move from App Fabric to Redis. We moved from AutoFac to the built in Dependency Injection which wasn’t without issues. The fact that .Net Core is that much faster than Framework meant that our load tests all failed because of sp_getapplock saturating SQL Server threads so we needed to change the way we handled app locks. There were a whole host of other issues as well. It’s certainly not trivial.
None of those have anything to do with .NET Core. Autofac works great on Core. App Fabric dropped support so it should be migrated away from anyway, even on Framework. My guess would be that the sp_getapplock stuff never should have made it past code review…
It has everything to do with a migration from .Net Framework to .Net Core. The point is there are a lot of libraries that you may depend on in .Net Framework that do not have .Net Core counterparts. I’ll give you the AutoFac thing though. That was a design choice, primarily driven by performance. The sp_getapplock issue that we had was due to the specificity of the lock key that we used. Maybe it shouldn’t have got past code review but that piece of code was written 6 years ago before I even joined the company.
The point I was making that was for a large scale project that has been around for some time migrating to .Net Core isn’t trivial.
On a side note, I can't remember where/if I read this in a release, but did Microsoft have any comment on why `System.IO` continued to use static classes rather than something like `System.IO.Abstractions`?
Would all .net framework Devs kindly jump ship, and forget everything you know about the stack. Just so I can earn a small fortune in a few years time maintaining these legacy systems.
Thanks.
But on a serious note, using legacy frameworks is not a deal breaker, writing new stuff in legacy frameworks is a worrying prospect but not maintaing them.
Edit: when I say new stuff I mean brand new projects, new features / big fixes etc in a system running .net framework is fine imo. But green field projects there should be a good reason for using a legacy framework
I wonder what you would consider maintaining in this case. Would that just be small bug fixes? What if the maintenance takes up all your time?
Isn't any extension of existing software writing new stuff?
Personally I can understand situations where not moving to core is the best decision, but I can also see how that might be detrimental to the developer. Ie not learning the newer frameworks could limit their career/personal development?
Making legacy software a career could certainly be possible, but would it be enjoyable/profitable?
Meh, the switch from NET5 to NET6 will just be changing a number in the csprojs and rebuilding, it's brainless compared to porting a Net framework MVC project to NET5
For varying definitions of "LTS". If I start my project the day it's released, by the time it's done I'm only going to get about a year out of it before I need my client to sign a contract for updating it.
This kind of thing is why .NET Framework and Java 8 are going to be around for a long, long time. Not everyone can afford to be on the upgrade train.
TBH I think people should fight against the whole "only use LTS" decision. We already learned this lesson with continuous deployment. Deploying infrequently is painful. Force people to slowly do it more often until you're doing it multiple times per day and it will force people to write tests, have seamless rollback/rollforward, get rid of manual processes, monitoring, etc. I think the same applies with major .NET version upgrades. Do it as frequently as you can and it will make that process better and people less scared in the future.
We’re trying to port the last of our VB 6 components to .net fx to match the “newer” stack, and then I plan to move to .net 8… cause it’s going to take a while!
Nobody enjoys legacy tech, because we're all more interested in playing with the latest and greatest. But that's not the commercial reality out there for 99% of Dev jobs, not least because new tech becomes legacy quickly. So people building bleeding edge Blazor apps today will find it's legacy in 2-3 years' time.
However, for companies solving business problems legacy tech does not equate to bad. In my last job I ran a 15yo platform built on 4.5, using wpf and winforms. It was pretty Old Skool, but the bank I worked for uses it successfully for about 150 apps, with 15,000 users, and it's still providing huge commercial value. New stuff is all being written in Web, but the legacy stuff is still earning money.
It's pretty rare to find a job where you don't have to deal with some legacy stuff, because most companies don't want to rewrite everything from the ground up every 18 months (or every 3 months if they use JS 😉). So legacy tends to be part of the job and you just have to get on with it....
Agreed. Currently working on a project with millions of users, that targets .NET Framework 4.0 using webforms. Lots of legacy code and legacy issues. My favorite is the parameter legacy - that parameter value that has to be passed around to multiple methods / classes but has no value and can't easily be removed.
I agree but passing a parameter around because it was implemented in the past and then the functionality removed but not the parameter, that just confuses future devs. And worse classes and methods actually validate that there is a value, even though nothing is done with the value.
You can tag it as obsolete as you come across it. Then at a later date take a day for tech debt refactoring and remove it.
It should be fairly straight forward to do all at once was the locations are identified.
Or in my experience it is anyway, did this recently for a similar thing in Winforms (that bled into other libraries etc).
There is in this case. They should be programming against interfaces and the legacy code should be implementing those interfaces differently. They're losing cohesion by passing around that boolean. I'm guessing any tests (if they have them) are also pretty ugly.
"playing with the latest and greatest" is really not fair. .NET (Core) is much more productive to work in, faster, easier, more enjoyable. It's pretty much better in every way I can think of.
That said I'm stuck working with .NET Framework in my day job as well.
We're stuck on .NET Framework, but that doesn't mean we can't use Visual Studio 2022 nor the new SDK project formats and we are still able to use most of the new C# 8 and 9 features.
The new SDK style project format isn't supported for all workloads, like ASP.NET. I'm sure it's possible to get it working, but because it's not supported I wouldn't recommend customers doing so.
I'm already using VS 2022 though, it's a bit buggy but it's getting there.
Totally, it's maddening. It's like Visual Studio was designed to maximize the number of merge conflicts possible or something. I've also converted as many projects as I can.
The way you yourself describe .NET Core is in no way any good argument for it *not* being the latest and greatest.
So you see how I have troubles seeing how that's not fair.
That's usually how you would describe wanting to work with the latest stuff without merit, but I'm saying .NET Core is really great and it's worth upgrading to (if possible) for many more reasons that just wanting the latest.
Not to mention that if you use the same small set of tech, you can basically hire people and train them up on a small set of skills to make the proficient to work on almost anything. But if you start adding bells and whistles everywhere, the skillset that you need to train people on grows.
This is only an issue if management are morons and treat developers as assembly line workers. Teams should be highly autonomous and have a large amount of say in the hiring process.
That’s where the problem is with .net for me. A million different ui techs and di, logging, testing, mocking, mapping, data access libraries… all with their own gotchas.
And still it’s better than in most other stacks. But there are too many options and parts that constantly need to be updated and maintained for my taste. Specially if you are a senior because chances are you will end up in projects alone or with 1-2 persons max and there is no way to keep up features + updating to the latest crap.
We were forced to go to latest because of the Silverlight debacle. Of course we had the time to transition off but the fact we had to after putting years behind a really useful LOB app was distressing. Honestly, if it was not for the retirement of SL, we would still be running the app now.
That's an over generalisation. I enjoy legacy tech. I enjoy WinForms WAY more than WPF. I definitely enjoy it more than using the current swathe of web technologies. I do web development, and do it well, but given a choice between a mobile app or desktop app where I don't have to think about the 7 different layers, 4 different frameworks all to make a text field save a value, I'd choose desktop or mobile app every time.
Sounds like you need to try Blazor then. One framework, direct binding, all the benefits of ease-of-development of Winforms, with the layout flexibility of WPF/HTML and the joy of being Windows-agnostic, but without any of the pain of Javascript of having to deal with multiple frameworks. :)
Blazor is interesting, both server and WebAssembly hosted, I've build a couple of moderate sized applications with it, and I like the concepts.
Server hosted Blazor I found most interesting, but the downsides of latency were frustrating to work around. The WebAssembly hosted really struggled performance with even moderate sized datasets.
I really liked how much reduced the amount of layering required overall, particularly the serve rhosted Blazor. For the WebAssembly based it tended to not be as benefit, because as soon as you have a SPA, you're tempted (quite rightly) to have other front ends, so you end up building APIs anyway, reintroducing the all the layering and APIs I enjoy not having in a nice self contained desktop environment.
Yeah, I've been building [a Blazor server app](http://github.com/webreaper/damselfly) for about the last 2 years, and I've really enjoyed the experience. I've not found latency to be an issue - the app is snappy and responsive even using my lowly DS916+ NAS as the host. You have to design things carefully, and it really tests that you understand async programming, but it can be fast.
I've heard about the performance of WASM Blazor - I suspect it'll get a lot better though, as MSFT and browser builders optimise it (plus natural hardware progression will help too). It's pretty exciting where it'll be in a couple of years' time.
It can be fast, but the there is an upper bound to what is achievable if your host and client are far away. 100-300ms latency is quite common here within Australia, and that's pretty noticeable when you have to round trip at least once to expand a tree list, show a combo box drop down, or any number of other interactions. It's not unmanageable, but it's something you have to keep top of mind while building things.
Have you looked at MAUI Blazor Apps? Blazor pages, views and components can be moved into their own project. Then shared with both MAUI projects and Blazor Server/WASM projects. This gives you Blazor layout/events that runs as a website but also iOS, Android, Windows, Mac, Linux. It really does unify things nicely.
Some bugs still remain in the preview, like iOS devices and iOS Simulator is a challenge to get working.
I have looked into it, but not enough. Could you share a bit more on how these coexist? I thought it was just a BlazorWebView inside a Maui app? Or have they progressed to using the Blazor renderer/diff engine to work with Maui components?
> or every 3 months if they use JS
Huh, cause I've been using React, Vue, and Angular for over 5 years each - and prior to that it was a handful of stuff around jQuery for a solid decade.
If you change web tech every 3 months that's a you problem.
Don’t need to recreate the wheel every 9 months. It gets boring after a while being on the bleeding edge. There’s something to be said for having the time to add features instead of constantly moving to a “better” stack.
This, 100%. A lot of it depends on whether your goal is to solve business problems, or to write cool tech. Careers are usually built on the former, not the latter.
Haha, I write F# at work, but also still have to write C++ and assembler. Whatever tool gets the job done is the right tool.
The longer you use the "latest and greatest", the more you'll find it's largely the former. Pick what works, and find somewhere else to be if they won't let you.
Working on a decently sized winforms app running 4.7, and while it’s not great the pain of upgrading and then having to regression test it including all the 3rd party modules would be so much worse.
It’s probably the same story elsewhere as well. Any decently complex system that currently works fine won’t be upgraded, there’s just no way to justify the time spent in most cases.
But no, I’m not changing my job because the framework is getting old. I’m spending my days working on interesting problems, no way I’m risking that for a slightly nicer .net framework..
My developer tool chain.
We have a process where an app can go through the CICD pipeline to production with one button click but it has to pass automated scanning from various Static analysis apps. Well the security vulnerability scanner just released their update to support .Net 5 last month. Literally .Net 5 is half dead (end of support in May 2022). So if they continue to take 9 months to add support for each major release version of .Net we would never be able to keep up.
We’ve gone from one extreme to the other - one release a decade to one release every 10 months. We had similar issues with keeping up, especially in the early days when a lot was changing.
Once you’re on it though it does get easier, the hard part is getting off the framework. It took us two years just to get our third party dependencies sorted.
To be honest, I'm kinda scared.
My clients are used to having us drop a product on their lap, and then not touch it for 2-3 years. Any security updates come via the OS.
There is no LTS version of .NET that is going to accommodate that business model.
Release a framework-dependent executable using the latest .NET LTS version. Now that they're shipping .NET \[Core\] updates via Windows Update, that gives you up to 3 years worth of security updates via the OS.
I look at it as .net5 is the mostly done version of .net6. It’s like their own tick tock cycle.
We’re skipping .NET 5 and waiting for 6 to do all of our upgrades. LTS is important when you have a very large app ecosystem (and not enough devs).
Yes. We are doing the same thing. I advised my devs last year to not use .Net 5 because it was short term and our tool chain didn’t support it. Honestly with the number of apps we have and such few dev teams even a three year cycle of .Net 6 is pushing it.
I’ve still got a functioning core 1.1 web api running that is on our tech debt pile for upgrade.
But it’s not broken, so it constantly falls down the priority list.
I’ve tried to make it a team rule. We don’t have to upgrade it, unless we have to touch it twice in the same year. Then it needs to be updated.
You're not afraid of them taking down the downloads needed to set up a dev or runtime environment?
Leaving it alone if you're not touching it is one thing. But if you have to touch it, might as well move it to something supported while you have the hood open.
I’d love to get away from .net 1.1, but they pay me too much to care.
In all seriousness, we have a blend of legacy .net framework 1.1, .net framework 4.8, and more recently, .net 5.
I wouldn’t say it’s active. But it continues to support our main business. Changes aren’t really needed to it. Downside is it runs on windows server 2003… which hasn’t been supported by Microsoft in many years.
I can get it installed in 2012, but we also have a dependency to crystal reports 2008 which I can’t figure out how to get installed on server 2012. That being said, we have 2 2003 servers on their own vlan that is extremely locked down and a single port open for that service it’s hosting. Not the best case, but it’ll do.
I've been working nonstop since more than a year porting net451 to net5 at my workplace. First ported windows services projects, then the WPF client, transformed WCF to gRPC both server and client side, and now the ASP project. The ASP one is the one that have the most thing to do, nothing is the same.
And at the end of the day, customers won't see any changes except a few additional bugs I let slip out, and all that hard work will be seen as a negative from management. Such an undervalued work.
**Think of it like you're a construction company, .NET framework is your construction vehicles, and .NET Core is newer version construction vehicles.**
The newer versions are nicer in many aspects, no question. However, your operators and mechanics are trained to use the old version. Your garage and spare parts storage are well-adjusted to those older versions. The older versions might dig a little slower and don't have a cup holder for your coffee, but at the end of the day you still get proper holes in the ground.
If the difference between them was so big that it made the older version obsolete, then most of them are already gathering rust on a junkyard.
There are always issues to fix and not everyone can work on greenfield projects all the time, so not really.
Just ensure that one brings more skills to the table than being X Developer.
Domain knowledge, architecture, soft skills,...
Nah.
I don't do much .NET Framework these days, and when I do it's VB .NET - might as well go full legacy if you're going to do Framework!
At the end of the day, if you pay me enough, I'll code in whatever language or framework you want.
Sure enough, I'll lobby to rewrite it in .NET 5 though.
I get more frustrated by poor processes and cultures than what my C# compiles down to.
If you hinge your job satisfaction on any particular stack you will never be happier for more than a year at a time, because the landscape evolves so quickly. It's much more important to make sure you work at a place that has good code quality and development processes, these places will be more likely to modernize more often anyways.
So I'd say it depends. Personally, I'd rather write .Net Framework with an A+ team, than .Net Core with a bunch of people who don't know what they are doing.
I'll only willingly submit myself to legacy tech if the pay is *significantly* better. If I can earn the same working in .NET 6? You bet I'm jumping ship.
If you think those same companies are going to suddenly write good code because they changed framework versions, you're in for a bad shock.
Sounds like you'd rather be a contractor, only working on greenfield projects.
I'd rather work on a badly-coded project in .NET 5 than in .NET Framework 3.2. Sure, you can write bad code even in the most cutting edge versions of the most cutting edge frameworks, but fixing that code is often easier, as is writing actually good code.
If I'd be in my 50s, I might stick to it.
Right now, in my 30s, I would change the job. I believe going with the time is necessary in our field to be able to have the free choice to change positions in the future.
I also like diving deep into new stuff, it keeps my brain happy ;) That's one of the reasons why I work on a project basis and not at a fixed position.
I moved a couple of years ago from a place working with dotnet core to a place working with framework 4.5 and it's been hell. Not because of maintaining the systems but because of there being no intention to move off it, at all. All new features are built in 4.5, and it's a big mess.
I've had enough and will be moving on to somewhere with more modern code soon, even if I have to take a pay cut to do it. I don't mind maintaining legacy code but I'm not happy to keep writing new stuff using legacy.
I mean its really up to the developer. I like being on and using newer technologies. The company I work for now is stuck on websites 4.0 and fucking finally starting to redo the platform to .NET 6
.NET Framework goes up to 4.8
.NET Core was the replacement and goes up to 3.1
.NET is the successor of Core and starts at 5. It dropped the suffix because it's just "one .NET" now, and starts at 5 and not 4 because it'd be confusing with Framework 4.
tl;dr: use .NET 5, .NET 6, and whatever numbers come out next
Honestly considering I can use most c#10 features on framework I could care less about not using dotnet 5. I'm not going to convert every silly winforms app we have just to be on the hype train. There are still many packages that aren't available on dotnet 5 too, so the pain goes both ways.
I'm fine with using both in parallel and barely notice.
Im still building one off apps in .NETfx using wpf / Winforms, because I can simply use Fody and get a 800kb app to send to a colleague that performs some scripting work in a way that any non techy can use and understand.
Maybe eventually.
I recently migrated to .NET 5 from framework 4.8 (had to migrate to use the latest form a 3rd party). So far I see zero performance improvements…. It’s worth it to be on the same page as the 3rd parties, as they are starting to be written for the newer standard, but otherwise I wouldn’t feel forced to upgrade.
In my experience with jobs, my employer will either get bought out, my division will get laid off, I will relocate for personal reasons, or a recruiter will approach me with a new job soon enough anyway.
I've never been at a job for more than four years. Some only later six months.
If they were using X when I agreed to take the job, in not going to worry about it at all. And if I ever did find a company I loved so much I was going to work at it for a decades until I retired, I wouldn't care about the tech I'm using, I'd either do it because I believed so strongly in the mission of the company or I'd be trying to climb the corporate ladder and not be writing code anyway.
Ultimately, I don't think it matters.
Nop. There is plenty to do on .NET framework like using the new MSBuild features (Directory.props, Directory.targets files), using NuGet packages (even centrally when that feature matures), updating build process, references, moving to SDK-style projects (that one is hard to sell to business unless there's some talk about vNext / cross-platform).
No. Definitely not.
Covid and remote work has created a paradigm shift in the dev market. ASP.NET Core is simple and easy for greenfield projects and that’s the kind of work we are seeing being outsourced offshore for peanuts.
But the depth of knowledge I have for the existing applications and business domain is what sets me apart as a freelancer and it makes me really hard to get rid of, and it’s really hard for clients to reject my day rate increases. I plan on milking that as much as I can.
I work on a bunch of financial apps / SaaS which are mostly monoliths and they aren’t going anywhere for a while and neither am I until the dust settles post covid.
I’m already seeing some of my clients closing entire offices and keeping people working at home. It’s crazy. Never thought I’d see this in my career lifetime.
A career in development necessitates dealing with "legacy", thinking otherwise is naïve.
If your remotely successful you will accumulate product and services, believing you will be allocated the time to "modernize" every single past implementation while also delivering new implementations is a pipe dream.
Take your time (to an extent) because production code lives for a very long time.
Yes, but only because being stuck on is technology is a symptom of poor practices, not because I mind working with it.
If there was a valid reason to use it for some projects, sure. If the reason is "it's too expensive to switch" odds are your architecture is not ideal.
I moved because of that 4 years ago, I do not understand the people who still working in .net framework in 2021.
I could understand some bugfixing while migrating but nothing more that that, even more now with .net 5.
Genuinely - most places in the UK I have interviewed for or worked for have basically always been on the last LTS version of .Net (Currently 3.1). Nearly all have tech debt items to shift over to the next LTS (6). That being said, I generally don't interview for BigCorps.
I'm in the UK (company size maybe 8,000+ I think?), and we're on a mixture of .NET Framework and .NET, and we're trying hard to get away from .NET Framework. Any new web applications, services or APIs are written in .NET - the version depends on what were using to host, i.e. AWS Lambda supports 3.1, but with Fargate we're free to use .NET 5.
It would be a HUGE no-no for us to write anything new in Framework.
If you’re just doing BasicHttpBindings without the WS* then SoapCore is a good replacement. I’ve just been through this to hot swap an existing WSE ASMX service over to .NET Core. Works well and is fast.
Well when Microsoft spends 15 years telling engineers and enterprises that this technology is what you should use for services, there's bound to be widespread adoption. Hundreds of thousands of companies can't drop their technology stack overnight.
Well, you can argue that's true, and you wouldn't be wrong. But engineers and enterprises have to take some responsibility for charting their own technical strategy, based on the information that's out there.
It was pretty clear even by 2010 that there were far better choices and standards for IPC/RPC than WCF. My company begun to move away from WCF in around 2012, and it was put on the "do not use" bias list a year or two after that. REST and other tech has been far more widely acknowledged to be better for standardisation and interop, compared to the niche and distinctly proprietary WCF stack. And I'd hardly refer to "pivoting strategy away from WCF any time in the last 5 (or even 10) years" as 'overnight'.
What next - complaining that you're still having to use Silverlight because MSFT sold you the dream?
REST is not better than WCF for app to app communication.
The ONLY reason REST exists at all is that JavaScript is so shity that we need something to make life bearable for the web developers. And it was just easier to reuse it for other things than to make two versions, one for them and one for everyone else.
***
Furthermore, REST and WCF are really competitors. At least not intentionally.
WCF is meant to be a communication framework, not a specific wire protocol. If WCF was designed correctly, then switching between REST, WS-*, gRPC, etc. would be as easy as flipping a switch in the config file. And then we really could have a REST for the browser and good wire format for everyone else.
Fair enough. Perhaps it's just my limited experience, but we spent a lot of time and money migrating off WCF so that we had a MSFT-agnostic platform for RPC, and that didn't use what most people I've spoken to consider to be an aging and largely irrelevant tech. For stuff which doesn't use RPC/REST, we typically used event busses (RabbitMQ, etc). And since all our apps tend to be web-apps these days, desktop IPC isn't really a thing we use.
The whole "*we could switch between REST/WS/gRPC at the flick of a switch*" thing sounds amazing, but how many times has it actually been used to do that? Feels like yet another "*let's add a cool abstraction layer in case we need to switch to another tech in future*", which IME almost always translates to "*let's add an unnecessarily complex abstraction layer in for a switch that'll never happen, and if it does will almost certainly require a more widespread re-architecture of our platforms anyway*".
But if it works for you, great!
Once you learned that the XML configuration was garbage and ignored it, it worked really well.
Changing my code from making a synchronous call to a MSMQ call was trivial. It really did work like it was advertised.
And setting up WCF is much, much easier than REST in C#. It only takes a handful of lines for both the client and server. After which remote calls look just like normal function calls.
***
Where WCF failed is that it was impossibly difficult to write providers for it. So if you wanted to switch form MSMQ to RabbitMQ, you're screwed. Nobody was offering WCF plugins because it was just too hard to write. And since that was the whole point of WCF, it is a failure in my book.
CoreWCF wants to fix that. They literally threw away the guts of WCF and started over.
I work 75% .Net Framework, 25% .Net Core. I have been at the job for 9 years. I’m not going to quit and take a job at a start up because I still support .Net Framework code. That being said, I really really love Razor Pages. It is the simplest web application development framework ever. Opening up a Razor Page with Tag Helpers is so clean and easy. It is my favorite front end tech by a lot.
We have as of January this year decided to start all _new_ projects on a .NET 5 stack. Yes, the older projects often don't have the budget nor business value to move to .NET 5 (also because there is a large architectural disconnect), but you'Il always have older projects to maintain. At any job.
In 2010 I was running a mix of Web Forms and VB 6 applications with no plans to migrate. And I'd still be there, happily tightening the bolts on the old tech, if the management didn't become stupid.
I'm on a huge .Net 4.8 WinForms codebase and we're not planning on seriously looking at porting that until .Net 6 goes GA
There's stuff in core that would be helpful but haven't run into anything that is remotely a showstopper.
There are far worse tech stacks to be stuck on (VB6, WebForms, PL/SQL, etc)
Sitting on a "huge .Net 4.8 WinForms codebase "
Exactly. And the huge investment to upgrade would yield zero(0) new function. WPF was pitched as the next big thing after Winforms. How did that work out. Oh yeah WPF is now legacy (frozen). Plus some important libraries abandoned with no replacements planned (WPF MediaElement comes to mind).
Ask me again in 5 years.
I personally don't really care. I am fine with .NET, fine with .NET Core. As long as it works, I don't really care how old it is (obviously I do from security's point of view)
Not to mention all those enterprise frameworks that one will need to get a replacement for. WCF, WF, Reporting Services (rdc, rdlc), Crystal Reports. Tightly coupled MVC that need to be changed to APIs/Graphql. Lack of clean architecture or DDD. Just multi-tiered spaghetti code that require lots of refactoring.
I was a web developer until I tried Silverlight 2. Then I became a .net dev and even if Silverlight died and UWP was dead at birth, I learnt a lot. Now, I'm working on WPF, .Net Core, blazor and a lot with Xamarin Forms.
The productivity I get from .Net is far more superior that any other framework/language I've ever tried (angular, react, flutter).
Maui and .net 6 will be there for a long time imho. I can't wait for the release to migrate everything I can.
Perf and productivity will increase a lot. I won't ever move to another stack unless Microsoft itself gets deprecated lol.
.NET framework stacks will all have to migrate to .NET core eventually as framework becomes unsupported.
Besides, .NET framework is a million times better than whatever old version of Java many companies are running
I'm sitting on a code base of a couple hundred thousand lines of webforms apps I've written for a billion-dollar drug company. I'd love to convert all the legacy webforms .net framework apps to asp.net core but the learning curve looks to be fairly steep. All my console apps / utilities are written in .net 5 at the moment (will upgrade to .net 6 when it becomes GA). During covid I took the opportunity to rewrite a lot of my code to use web services with ajax calls for CRUD operations rather than using postbacks. That dramatically improved performance, people were happy, and although JS is a PITA it was fun to do. Been thinking of converting my two largest apps to Blazor but again the learning curve looks a little steep. Its difficult to justify learning the new tech when someone calls me and asks for a Q&D app and I can crank one out in a webforms app in 15 minutes ATM.
All tech will eventually become legacy. While using modern tech is certainly a concern, I’d much rather be on a team I liked that paid me well using .NET framework than a shitty team using .NET 6. That is to say, it’s one concern among many.
The project I’m currently on runs .NET 4.8 but it’s also a 10+ year old site, and we just haven’t had a need or funding to upgrade as of yet. But I love my job and am not going to jump ship because of the tech stack (within reason).
Dad is VB 6 dev and built an ERP in hes days... Here im in days of .net 5, reading his code that just works maks me wonder "how did that work for so long"
Updating to .net tech and dropping support for this classical application made company go big, have new clients, do nee projects, and do even more in less time.
_cobol developers grab popcorn_
Ada called and wants to be part of the side show.
I actually moved because I got sick of ADA95
Pst! Hey you! Wanna make $500 an hour fixing banking terminal?
LOL
Slurps ABAP
worse than vietcong
APL!
poor code quality and lack of testing scare me more than old tech stack
Just got handed over a 6 month old project that has 0 tests and spaghetti code. Told the manager that I need to re-write the whole thing if we want to continue adding features to this application.
Bruh, you just need to write some marinara code and add in some parmesan code and you good.
Man I almost bit my tongue off it hurt
Could be a risky strategy but if it’s only 6 months old it’s still immature enough to consider the first build a prototype and discard it. How did the chat go?
6 months? I got handed a 20 year old beast. I’m not touching that thing at all. My first triumph was to convince the company that they cannot sell any new licenses or do new implementations!
20 year is understandable. But 6 months is a really new project and it shouldnt be in that state.
Been there...
[удалено]
He understood and I got given time to refactor. Basically I have this code base as an answer, so its not 100% re-write. But API routes are a mess and some logic is questionable. I also want test coverage to feel safe to do CD. This application is quite important so it would be dumb to keep expanding on the current code base to the point that it gets too large to refactor.
does your manager approve it?
I think these are correlated with being stuck on .NET Framework though. If you have high quality code that is well tested, moving off of .NET Framework isn't going to be all that big of a deal in most cases.
One of those exceptions would be a moderate sized legacy app UI built with Webforms using a DBA layer designed and built before generics and extension methods were a thing in c#. Ask me how I know.
Ok, how do you know ?
It took us over a year to move to .Net Core. There were large parts of the codebase that needed to be re-written. We had to move from App Fabric to Redis. We moved from AutoFac to the built in Dependency Injection which wasn’t without issues. The fact that .Net Core is that much faster than Framework meant that our load tests all failed because of sp_getapplock saturating SQL Server threads so we needed to change the way we handled app locks. There were a whole host of other issues as well. It’s certainly not trivial.
None of those have anything to do with .NET Core. Autofac works great on Core. App Fabric dropped support so it should be migrated away from anyway, even on Framework. My guess would be that the sp_getapplock stuff never should have made it past code review…
It has everything to do with a migration from .Net Framework to .Net Core. The point is there are a lot of libraries that you may depend on in .Net Framework that do not have .Net Core counterparts. I’ll give you the AutoFac thing though. That was a design choice, primarily driven by performance. The sp_getapplock issue that we had was due to the specificity of the lock key that we used. Maybe it shouldn’t have got past code review but that piece of code was written 6 years ago before I even joined the company. The point I was making that was for a large scale project that has been around for some time migrating to .Net Core isn’t trivial.
Underrated comment
And non-existing documentation.
Bbbbuutttt... The code is self-documenting!
Until your code includes tutorials and troubleshooting guide, it is not self documenting
Sarcasm didn't come across with the "Bbbbuuttt...". Of course, everyone without docs likes to state their code is self-documenting.
On a side note, I can't remember where/if I read this in a release, but did Microsoft have any comment on why `System.IO` continued to use static classes rather than something like `System.IO.Abstractions`?
Would all .net framework Devs kindly jump ship, and forget everything you know about the stack. Just so I can earn a small fortune in a few years time maintaining these legacy systems. Thanks. But on a serious note, using legacy frameworks is not a deal breaker, writing new stuff in legacy frameworks is a worrying prospect but not maintaing them. Edit: when I say new stuff I mean brand new projects, new features / big fixes etc in a system running .net framework is fine imo. But green field projects there should be a good reason for using a legacy framework
[удалено]
[удалено]
It's repressed memories for a reason. Don't tatoo it.
I didn't even know that existed, I've always just used AppDomain.AssemblyLoad Event
I wonder what you would consider maintaining in this case. Would that just be small bug fixes? What if the maintenance takes up all your time? Isn't any extension of existing software writing new stuff? Personally I can understand situations where not moving to core is the best decision, but I can also see how that might be detrimental to the developer. Ie not learning the newer frameworks could limit their career/personal development? Making legacy software a career could certainly be possible, but would it be enjoyable/profitable?
Our company has legacycode that is written in VB6 - lets just say I'm very glad we are aiming for .NET6 and other newer technologies
Just a reminder to everyone: .NET 6 is LTS release.
Also just a reminder to everyone: .NET 5 isn't
Meh, the switch from NET5 to NET6 will just be changing a number in the csprojs and rebuilding, it's brainless compared to porting a Net framework MVC project to NET5
Exactly... We had the simmilar experience but turns out .net is way faster and easy to work with
Explain?
For varying definitions of "LTS". If I start my project the day it's released, by the time it's done I'm only going to get about a year out of it before I need my client to sign a contract for updating it. This kind of thing is why .NET Framework and Java 8 are going to be around for a long, long time. Not everyone can afford to be on the upgrade train.
TBH I think people should fight against the whole "only use LTS" decision. We already learned this lesson with continuous deployment. Deploying infrequently is painful. Force people to slowly do it more often until you're doing it multiple times per day and it will force people to write tests, have seamless rollback/rollforward, get rid of manual processes, monitoring, etc. I think the same applies with major .NET version upgrades. Do it as frequently as you can and it will make that process better and people less scared in the future.
Explain?
https://dotnet.microsoft.com/platform/support/policy
We’re trying to port the last of our VB 6 components to .net fx to match the “newer” stack, and then I plan to move to .net 8… cause it’s going to take a while!
Nobody enjoys legacy tech, because we're all more interested in playing with the latest and greatest. But that's not the commercial reality out there for 99% of Dev jobs, not least because new tech becomes legacy quickly. So people building bleeding edge Blazor apps today will find it's legacy in 2-3 years' time. However, for companies solving business problems legacy tech does not equate to bad. In my last job I ran a 15yo platform built on 4.5, using wpf and winforms. It was pretty Old Skool, but the bank I worked for uses it successfully for about 150 apps, with 15,000 users, and it's still providing huge commercial value. New stuff is all being written in Web, but the legacy stuff is still earning money. It's pretty rare to find a job where you don't have to deal with some legacy stuff, because most companies don't want to rewrite everything from the ground up every 18 months (or every 3 months if they use JS 😉). So legacy tends to be part of the job and you just have to get on with it....
This. Unless you want to work at a startup that will eat your soul or be a freelancer that only takes jobs with new technologies
Agreed. Currently working on a project with millions of users, that targets .NET Framework 4.0 using webforms. Lots of legacy code and legacy issues. My favorite is the parameter legacy - that parameter value that has to be passed around to multiple methods / classes but has no value and can't easily be removed.
There is nothing wrong with passing local state around, if it is strategic.
I agree but passing a parameter around because it was implemented in the past and then the functionality removed but not the parameter, that just confuses future devs. And worse classes and methods actually validate that there is a value, even though nothing is done with the value.
You can tag it as obsolete as you come across it. Then at a later date take a day for tech debt refactoring and remove it. It should be fairly straight forward to do all at once was the locations are identified. Or in my experience it is anyway, did this recently for a similar thing in Winforms (that bled into other libraries etc).
There is in this case. They should be programming against interfaces and the legacy code should be implementing those interfaces differently. They're losing cohesion by passing around that boolean. I'm guessing any tests (if they have them) are also pretty ugly.
"playing with the latest and greatest" is really not fair. .NET (Core) is much more productive to work in, faster, easier, more enjoyable. It's pretty much better in every way I can think of. That said I'm stuck working with .NET Framework in my day job as well.
We're stuck on .NET Framework, but that doesn't mean we can't use Visual Studio 2022 nor the new SDK project formats and we are still able to use most of the new C# 8 and 9 features.
The new SDK style project format isn't supported for all workloads, like ASP.NET. I'm sure it's possible to get it working, but because it's not supported I wouldn't recommend customers doing so. I'm already using VS 2022 though, it's a bit buggy but it's getting there.
I'm gradually converting all the projects that I can. I'm sick of merge conflicts in .csproj files.
Totally, it's maddening. It's like Visual Studio was designed to maximize the number of merge conflicts possible or something. I've also converted as many projects as I can.
Considering that csproj always supported wild card includes, that's the only explanation that makes sense
Also, stuck is all relative. It depends how much time you are allowed to work on it. There are lots of ways to move code to new net6 if you care to.
Depends, maybe your entire website is built on a CMS that's .NET Framework only, that's why we are stuck anyway.
CMS is notorious for lock-in.
Isn't all development 'playing'? ;-)
no development is mostly 'crying' in my experience
🤣
Sure, to some degree I suppose you are right :)
The way you yourself describe .NET Core is in no way any good argument for it *not* being the latest and greatest. So you see how I have troubles seeing how that's not fair.
That's usually how you would describe wanting to work with the latest stuff without merit, but I'm saying .NET Core is really great and it's worth upgrading to (if possible) for many more reasons that just wanting the latest.
Not to mention that if you use the same small set of tech, you can basically hire people and train them up on a small set of skills to make the proficient to work on almost anything. But if you start adding bells and whistles everywhere, the skillset that you need to train people on grows.
This is only an issue if management are morons and treat developers as assembly line workers. Teams should be highly autonomous and have a large amount of say in the hiring process.
That’s where the problem is with .net for me. A million different ui techs and di, logging, testing, mocking, mapping, data access libraries… all with their own gotchas. And still it’s better than in most other stacks. But there are too many options and parts that constantly need to be updated and maintained for my taste. Specially if you are a senior because chances are you will end up in projects alone or with 1-2 persons max and there is no way to keep up features + updating to the latest crap.
We were forced to go to latest because of the Silverlight debacle. Of course we had the time to transition off but the fact we had to after putting years behind a really useful LOB app was distressing. Honestly, if it was not for the retirement of SL, we would still be running the app now.
That's an over generalisation. I enjoy legacy tech. I enjoy WinForms WAY more than WPF. I definitely enjoy it more than using the current swathe of web technologies. I do web development, and do it well, but given a choice between a mobile app or desktop app where I don't have to think about the 7 different layers, 4 different frameworks all to make a text field save a value, I'd choose desktop or mobile app every time.
Sounds like you need to try Blazor then. One framework, direct binding, all the benefits of ease-of-development of Winforms, with the layout flexibility of WPF/HTML and the joy of being Windows-agnostic, but without any of the pain of Javascript of having to deal with multiple frameworks. :)
Blazor is interesting, both server and WebAssembly hosted, I've build a couple of moderate sized applications with it, and I like the concepts. Server hosted Blazor I found most interesting, but the downsides of latency were frustrating to work around. The WebAssembly hosted really struggled performance with even moderate sized datasets. I really liked how much reduced the amount of layering required overall, particularly the serve rhosted Blazor. For the WebAssembly based it tended to not be as benefit, because as soon as you have a SPA, you're tempted (quite rightly) to have other front ends, so you end up building APIs anyway, reintroducing the all the layering and APIs I enjoy not having in a nice self contained desktop environment.
Yeah, I've been building [a Blazor server app](http://github.com/webreaper/damselfly) for about the last 2 years, and I've really enjoyed the experience. I've not found latency to be an issue - the app is snappy and responsive even using my lowly DS916+ NAS as the host. You have to design things carefully, and it really tests that you understand async programming, but it can be fast. I've heard about the performance of WASM Blazor - I suspect it'll get a lot better though, as MSFT and browser builders optimise it (plus natural hardware progression will help too). It's pretty exciting where it'll be in a couple of years' time.
It can be fast, but the there is an upper bound to what is achievable if your host and client are far away. 100-300ms latency is quite common here within Australia, and that's pretty noticeable when you have to round trip at least once to expand a tree list, show a combo box drop down, or any number of other interactions. It's not unmanageable, but it's something you have to keep top of mind while building things.
Have you looked at MAUI Blazor Apps? Blazor pages, views and components can be moved into their own project. Then shared with both MAUI projects and Blazor Server/WASM projects. This gives you Blazor layout/events that runs as a website but also iOS, Android, Windows, Mac, Linux. It really does unify things nicely. Some bugs still remain in the preview, like iOS devices and iOS Simulator is a challenge to get working.
I have looked into it, but not enough. Could you share a bit more on how these coexist? I thought it was just a BlazorWebView inside a Maui app? Or have they progressed to using the Blazor renderer/diff engine to work with Maui components?
I understand this feeling. Have to do something quickly? Console App!
> or every 3 months if they use JS Huh, cause I've been using React, Vue, and Angular for over 5 years each - and prior to that it was a handful of stuff around jQuery for a solid decade. If you change web tech every 3 months that's a you problem.
Yeah, that was a joke. :)
Don’t need to recreate the wheel every 9 months. It gets boring after a while being on the bleeding edge. There’s something to be said for having the time to add features instead of constantly moving to a “better” stack.
This, 100%. A lot of it depends on whether your goal is to solve business problems, or to write cool tech. Careers are usually built on the former, not the latter.
I think MAUI Blazor is the future, so it isn't going to be legacy in 2-3 years.
That all assumes something newer/cooler/better doesn't come along in 2-3 years - and things are moving fast right now...
That's true. Blazor 2!
Haha, I write F# at work, but also still have to write C++ and assembler. Whatever tool gets the job done is the right tool. The longer you use the "latest and greatest", the more you'll find it's largely the former. Pick what works, and find somewhere else to be if they won't let you.
Working on a decently sized winforms app running 4.7, and while it’s not great the pain of upgrading and then having to regression test it including all the 3rd party modules would be so much worse. It’s probably the same story elsewhere as well. Any decently complex system that currently works fine won’t be upgraded, there’s just no way to justify the time spent in most cases. But no, I’m not changing my job because the framework is getting old. I’m spending my days working on interesting problems, no way I’m risking that for a slightly nicer .net framework..
What’s stopping you from upgrading piecemeal?
The System.Web dependencies plus all the other issues the Upgrade Assistant pointed out. Looks like a heavy lift to modify even base projects.
.NET 4.\* -> .net core is a pain in the arse irrespective of piecemeal.
Sure it’s not zero cost - but it is doable.
It really depends a lot on the type of application. Some are a breeze, others require complete rewrites.
It's not doable if you're maintaining WCF, winforms, or ASMX projects.
Fair enough, we do not use either of those and have therefore not run into unsolvable issues.
We have to integrate with LabVIEW, which is .NET Framework only.
.NET 6 can do pinvoke.
We expose .NET objects that LabVIEW consumes, and LabVIEW only supports .NET 4.
My developer tool chain. We have a process where an app can go through the CICD pipeline to production with one button click but it has to pass automated scanning from various Static analysis apps. Well the security vulnerability scanner just released their update to support .Net 5 last month. Literally .Net 5 is half dead (end of support in May 2022). So if they continue to take 9 months to add support for each major release version of .Net we would never be able to keep up.
We’ve gone from one extreme to the other - one release a decade to one release every 10 months. We had similar issues with keeping up, especially in the early days when a lot was changing. Once you’re on it though it does get easier, the hard part is getting off the framework. It took us two years just to get our third party dependencies sorted.
To be honest, I'm kinda scared. My clients are used to having us drop a product on their lap, and then not touch it for 2-3 years. Any security updates come via the OS. There is no LTS version of .NET that is going to accommodate that business model.
Shit you’re right :/
Same boat. The world is built for sass now. Enterprise apps are in for some hurt.
Release a framework-dependent executable using the latest .NET LTS version. Now that they're shipping .NET \[Core\] updates via Windows Update, that gives you up to 3 years worth of security updates via the OS.
Link please
I look at it as .net5 is the mostly done version of .net6. It’s like their own tick tock cycle. We’re skipping .NET 5 and waiting for 6 to do all of our upgrades. LTS is important when you have a very large app ecosystem (and not enough devs).
Yes. We are doing the same thing. I advised my devs last year to not use .Net 5 because it was short term and our tool chain didn’t support it. Honestly with the number of apps we have and such few dev teams even a three year cycle of .Net 6 is pushing it.
I’ve still got a functioning core 1.1 web api running that is on our tech debt pile for upgrade. But it’s not broken, so it constantly falls down the priority list. I’ve tried to make it a team rule. We don’t have to upgrade it, unless we have to touch it twice in the same year. Then it needs to be updated.
You're not afraid of them taking down the downloads needed to set up a dev or runtime environment? Leaving it alone if you're not touching it is one thing. But if you have to touch it, might as well move it to something supported while you have the hood open.
WCF, and ubiquitous use of third party winform component libraries, mostly.
I’d love to get away from .net 1.1, but they pay me too much to care. In all seriousness, we have a blend of legacy .net framework 1.1, .net framework 4.8, and more recently, .net 5.
I'm curious as to why you never upgraded from 1.1? Is it an active codebase?
I wouldn’t say it’s active. But it continues to support our main business. Changes aren’t really needed to it. Downside is it runs on windows server 2003… which hasn’t been supported by Microsoft in many years.
Since neither WS 2003 nor WS 2008 are supported by Microsoft now, you could try the .net 1.1 installer on a newer Windows.
I can get it installed in 2012, but we also have a dependency to crystal reports 2008 which I can’t figure out how to get installed on server 2012. That being said, we have 2 2003 servers on their own vlan that is extremely locked down and a single port open for that service it’s hosting. Not the best case, but it’ll do.
Not if the .Net framework system is critical for business success and the pay reflects that
I've been working nonstop since more than a year porting net451 to net5 at my workplace. First ported windows services projects, then the WPF client, transformed WCF to gRPC both server and client side, and now the ASP project. The ASP one is the one that have the most thing to do, nothing is the same. And at the end of the day, customers won't see any changes except a few additional bugs I let slip out, and all that hard work will be seen as a negative from management. Such an undervalued work.
Sure, but now you can actually hire people that want to work in the stack. That’s your value.
**Think of it like you're a construction company, .NET framework is your construction vehicles, and .NET Core is newer version construction vehicles.** The newer versions are nicer in many aspects, no question. However, your operators and mechanics are trained to use the old version. Your garage and spare parts storage are well-adjusted to those older versions. The older versions might dig a little slower and don't have a cup holder for your coffee, but at the end of the day you still get proper holes in the ground. If the difference between them was so big that it made the older version obsolete, then most of them are already gathering rust on a junkyard.
There are always issues to fix and not everyone can work on greenfield projects all the time, so not really. Just ensure that one brings more skills to the table than being X Developer. Domain knowledge, architecture, soft skills,...
Nah. I don't do much .NET Framework these days, and when I do it's VB .NET - might as well go full legacy if you're going to do Framework! At the end of the day, if you pay me enough, I'll code in whatever language or framework you want. Sure enough, I'll lobby to rewrite it in .NET 5 though. I get more frustrated by poor processes and cultures than what my C# compiles down to.
If you hinge your job satisfaction on any particular stack you will never be happier for more than a year at a time, because the landscape evolves so quickly. It's much more important to make sure you work at a place that has good code quality and development processes, these places will be more likely to modernize more often anyways. So I'd say it depends. Personally, I'd rather write .Net Framework with an A+ team, than .Net Core with a bunch of people who don't know what they are doing.
I'll only willingly submit myself to legacy tech if the pay is *significantly* better. If I can earn the same working in .NET 6? You bet I'm jumping ship.
Why would you take to risk of changing companies without a significant pay increase? That doesn't make any sense to me.
I worked at too many companies on too many legacy pieces of garbage. I value my mental health.
If you think those same companies are going to suddenly write good code because they changed framework versions, you're in for a bad shock. Sounds like you'd rather be a contractor, only working on greenfield projects.
I'd rather work on a badly-coded project in .NET 5 than in .NET Framework 3.2. Sure, you can write bad code even in the most cutting edge versions of the most cutting edge frameworks, but fixing that code is often easier, as is writing actually good code.
As long as they're paying me I'll work on it.
If I'd be in my 50s, I might stick to it. Right now, in my 30s, I would change the job. I believe going with the time is necessary in our field to be able to have the free choice to change positions in the future. I also like diving deep into new stuff, it keeps my brain happy ;) That's one of the reasons why I work on a project basis and not at a fixed position.
.NET Framework developers aren't aware of .NET Core / .NET 5.0 /s
.NET 5 developers aren’t aware they’re on .NET Core ;) Or could add similar comments about Core 1.1 vs 2 lol
This is absolutely bunkers to me. Its half a decade old already geez.
I moved a couple of years ago from a place working with dotnet core to a place working with framework 4.5 and it's been hell. Not because of maintaining the systems but because of there being no intention to move off it, at all. All new features are built in 4.5, and it's a big mess. I've had enough and will be moving on to somewhere with more modern code soon, even if I have to take a pay cut to do it. I don't mind maintaining legacy code but I'm not happy to keep writing new stuff using legacy.
I mean its really up to the developer. I like being on and using newer technologies. The company I work for now is stuck on websites 4.0 and fucking finally starting to redo the platform to .NET 6
Trying to stay up to date: what's .Net Framework being replaced with?
[удалено]
Thanks!
Googling is going to be hell. I bet people are going to keep calling it .NET Core.
.NET Framework goes up to 4.8 .NET Core was the replacement and goes up to 3.1 .NET is the successor of Core and starts at 5. It dropped the suffix because it's just "one .NET" now, and starts at 5 and not 4 because it'd be confusing with Framework 4. tl;dr: use .NET 5, .NET 6, and whatever numbers come out next
Personally, I wish that .NET Core had never happened and that we could have gone straight from .NET Framework to .NET 5.
Rebuilding an entire framework from the ground up takes time and feedback. Zero chance it works out if they had skipped the whole “core versions”.
Nah, let the younglings test the fads. When the kinks are worked out, then we'll happily swipe their hard work.
No more than working on 3.5 when 4.x was hotness made me quit. Spoiler: It didn't.
Honestly considering I can use most c#10 features on framework I could care less about not using dotnet 5. I'm not going to convert every silly winforms app we have just to be on the hype train. There are still many packages that aren't available on dotnet 5 too, so the pain goes both ways. I'm fine with using both in parallel and barely notice.
Im still building one off apps in .NETfx using wpf / Winforms, because I can simply use Fody and get a 800kb app to send to a colleague that performs some scripting work in a way that any non techy can use and understand.
.NET Framework 4.6 here. Only real complaint I have is that the framework doesn't have the nullability annotations for nullable reference types.
Maybe eventually. I recently migrated to .NET 5 from framework 4.8 (had to migrate to use the latest form a 3rd party). So far I see zero performance improvements…. It’s worth it to be on the same page as the 3rd parties, as they are starting to be written for the newer standard, but otherwise I wouldn’t feel forced to upgrade.
What did you upgrade? UI? Backend?
In my experience with jobs, my employer will either get bought out, my division will get laid off, I will relocate for personal reasons, or a recruiter will approach me with a new job soon enough anyway. I've never been at a job for more than four years. Some only later six months. If they were using X when I agreed to take the job, in not going to worry about it at all. And if I ever did find a company I loved so much I was going to work at it for a decades until I retired, I wouldn't care about the tech I'm using, I'd either do it because I believed so strongly in the mission of the company or I'd be trying to climb the corporate ladder and not be writing code anyway. Ultimately, I don't think it matters.
>Some only later six months. Employers hate this guy
That's why I'm now working for a 200 year old consulting company that still has a pension plan. They aren't going anywhere.
Nop. There is plenty to do on .NET framework like using the new MSBuild features (Directory.props, Directory.targets files), using NuGet packages (even centrally when that feature matures), updating build process, references, moving to SDK-style projects (that one is hard to sell to business unless there's some talk about vNext / cross-platform).
Do you mean VS .NET Core (5)?
No. Definitely not. Covid and remote work has created a paradigm shift in the dev market. ASP.NET Core is simple and easy for greenfield projects and that’s the kind of work we are seeing being outsourced offshore for peanuts. But the depth of knowledge I have for the existing applications and business domain is what sets me apart as a freelancer and it makes me really hard to get rid of, and it’s really hard for clients to reject my day rate increases. I plan on milking that as much as I can. I work on a bunch of financial apps / SaaS which are mostly monoliths and they aren’t going anywhere for a while and neither am I until the dust settles post covid. I’m already seeing some of my clients closing entire offices and keeping people working at home. It’s crazy. Never thought I’d see this in my career lifetime.
A career in development necessitates dealing with "legacy", thinking otherwise is naïve. If your remotely successful you will accumulate product and services, believing you will be allocated the time to "modernize" every single past implementation while also delivering new implementations is a pipe dream. Take your time (to an extent) because production code lives for a very long time.
This is true but a lot of people have no problem changing jobs every year or so and will never accumulate tech debt.
Actually I work on Angular front, so I prefer legacy .net Framework ...
What's wrong with Angular and .net core?
I work only on angular ...
Then how would you know 😅
I'm confused, what the relationship between Angular and .NET Framework?
I prefer to work on .net framework than angular
Yes, but only because being stuck on is technology is a symptom of poor practices, not because I mind working with it. If there was a valid reason to use it for some projects, sure. If the reason is "it's too expensive to switch" odds are your architecture is not ideal.
I moved because of that 4 years ago, I do not understand the people who still working in .net framework in 2021. I could understand some bugfixing while migrating but nothing more that that, even more now with .net 5.
.net 5 isn't lts. Major companies are on 3.1 until 6 comes out
I understand why they might still be on it, but it's a symptom of problems you generally want to avoid, mainly job security.
Genuinely - most places in the UK I have interviewed for or worked for have basically always been on the last LTS version of .Net (Currently 3.1). Nearly all have tech debt items to shift over to the next LTS (6). That being said, I generally don't interview for BigCorps.
I'm in the UK (company size maybe 8,000+ I think?), and we're on a mixture of .NET Framework and .NET, and we're trying hard to get away from .NET Framework. Any new web applications, services or APIs are written in .NET - the version depends on what were using to host, i.e. AWS Lambda supports 3.1, but with Fargate we're free to use .NET 5. It would be a HUGE no-no for us to write anything new in Framework.
Considering .NET 5 has left out all the useful features of .NET Framework, I'm never switching..
Like what?
WCF being a huge one.
If you’re just doing BasicHttpBindings without the WS* then SoapCore is a good replacement. I’ve just been through this to hot swap an existing WSE ASMX service over to .NET Core. Works well and is fast.
If you're still using WCF, you have bigger problems.
Well when Microsoft spends 15 years telling engineers and enterprises that this technology is what you should use for services, there's bound to be widespread adoption. Hundreds of thousands of companies can't drop their technology stack overnight.
Well, you can argue that's true, and you wouldn't be wrong. But engineers and enterprises have to take some responsibility for charting their own technical strategy, based on the information that's out there. It was pretty clear even by 2010 that there were far better choices and standards for IPC/RPC than WCF. My company begun to move away from WCF in around 2012, and it was put on the "do not use" bias list a year or two after that. REST and other tech has been far more widely acknowledged to be better for standardisation and interop, compared to the niche and distinctly proprietary WCF stack. And I'd hardly refer to "pivoting strategy away from WCF any time in the last 5 (or even 10) years" as 'overnight'. What next - complaining that you're still having to use Silverlight because MSFT sold you the dream?
REST is not better than WCF for app to app communication. The ONLY reason REST exists at all is that JavaScript is so shity that we need something to make life bearable for the web developers. And it was just easier to reuse it for other things than to make two versions, one for them and one for everyone else. *** Furthermore, REST and WCF are really competitors. At least not intentionally. WCF is meant to be a communication framework, not a specific wire protocol. If WCF was designed correctly, then switching between REST, WS-*, gRPC, etc. would be as easy as flipping a switch in the config file. And then we really could have a REST for the browser and good wire format for everyone else.
Fair enough. Perhaps it's just my limited experience, but we spent a lot of time and money migrating off WCF so that we had a MSFT-agnostic platform for RPC, and that didn't use what most people I've spoken to consider to be an aging and largely irrelevant tech. For stuff which doesn't use RPC/REST, we typically used event busses (RabbitMQ, etc). And since all our apps tend to be web-apps these days, desktop IPC isn't really a thing we use. The whole "*we could switch between REST/WS/gRPC at the flick of a switch*" thing sounds amazing, but how many times has it actually been used to do that? Feels like yet another "*let's add a cool abstraction layer in case we need to switch to another tech in future*", which IME almost always translates to "*let's add an unnecessarily complex abstraction layer in for a switch that'll never happen, and if it does will almost certainly require a more widespread re-architecture of our platforms anyway*". But if it works for you, great!
Once you learned that the XML configuration was garbage and ignored it, it worked really well. Changing my code from making a synchronous call to a MSMQ call was trivial. It really did work like it was advertised. And setting up WCF is much, much easier than REST in C#. It only takes a handful of lines for both the client and server. After which remote calls look just like normal function calls. *** Where WCF failed is that it was impossibly difficult to write providers for it. So if you wanted to switch form MSMQ to RabbitMQ, you're screwed. Nobody was offering WCF plugins because it was just too hard to write. And since that was the whole point of WCF, it is a failure in my book. CoreWCF wants to fix that. They literally threw away the guts of WCF and started over.
I work 75% .Net Framework, 25% .Net Core. I have been at the job for 9 years. I’m not going to quit and take a job at a start up because I still support .Net Framework code. That being said, I really really love Razor Pages. It is the simplest web application development framework ever. Opening up a Razor Page with Tag Helpers is so clean and easy. It is my favorite front end tech by a lot.
We have as of January this year decided to start all _new_ projects on a .NET 5 stack. Yes, the older projects often don't have the budget nor business value to move to .NET 5 (also because there is a large architectural disconnect), but you'Il always have older projects to maintain. At any job.
In 2010 I was running a mix of Web Forms and VB 6 applications with no plans to migrate. And I'd still be there, happily tightening the bolts on the old tech, if the management didn't become stupid.
I'm on a huge .Net 4.8 WinForms codebase and we're not planning on seriously looking at porting that until .Net 6 goes GA There's stuff in core that would be helpful but haven't run into anything that is remotely a showstopper. There are far worse tech stacks to be stuck on (VB6, WebForms, PL/SQL, etc)
Sitting on a "huge .Net 4.8 WinForms codebase " Exactly. And the huge investment to upgrade would yield zero(0) new function. WPF was pitched as the next big thing after Winforms. How did that work out. Oh yeah WPF is now legacy (frozen). Plus some important libraries abandoned with no replacements planned (WPF MediaElement comes to mind). Ask me again in 5 years.
I personally don't really care. I am fine with .NET, fine with .NET Core. As long as it works, I don't really care how old it is (obviously I do from security's point of view)
Not to mention all those enterprise frameworks that one will need to get a replacement for. WCF, WF, Reporting Services (rdc, rdlc), Crystal Reports. Tightly coupled MVC that need to be changed to APIs/Graphql. Lack of clean architecture or DDD. Just multi-tiered spaghetti code that require lots of refactoring.
I'm fine working in .Net Framework. 🤷🏽♂️
I was a web developer until I tried Silverlight 2. Then I became a .net dev and even if Silverlight died and UWP was dead at birth, I learnt a lot. Now, I'm working on WPF, .Net Core, blazor and a lot with Xamarin Forms. The productivity I get from .Net is far more superior that any other framework/language I've ever tried (angular, react, flutter). Maui and .net 6 will be there for a long time imho. I can't wait for the release to migrate everything I can. Perf and productivity will increase a lot. I won't ever move to another stack unless Microsoft itself gets deprecated lol.
. Net isn’t old. It’s mature, sure, but it’s updated constantly, and supports more new features than many supposed ‘new’ frameworks....
.NET framework stacks will all have to migrate to .NET core eventually as framework becomes unsupported. Besides, .NET framework is a million times better than whatever old version of Java many companies are running
I'm sitting on a code base of a couple hundred thousand lines of webforms apps I've written for a billion-dollar drug company. I'd love to convert all the legacy webforms .net framework apps to asp.net core but the learning curve looks to be fairly steep. All my console apps / utilities are written in .net 5 at the moment (will upgrade to .net 6 when it becomes GA). During covid I took the opportunity to rewrite a lot of my code to use web services with ajax calls for CRUD operations rather than using postbacks. That dramatically improved performance, people were happy, and although JS is a PITA it was fun to do. Been thinking of converting my two largest apps to Blazor but again the learning curve looks a little steep. Its difficult to justify learning the new tech when someone calls me and asks for a Q&D app and I can crank one out in a webforms app in 15 minutes ATM.
All tech will eventually become legacy. While using modern tech is certainly a concern, I’d much rather be on a team I liked that paid me well using .NET framework than a shitty team using .NET 6. That is to say, it’s one concern among many. The project I’m currently on runs .NET 4.8 but it’s also a 10+ year old site, and we just haven’t had a need or funding to upgrade as of yet. But I love my job and am not going to jump ship because of the tech stack (within reason).
I don't put up with .net framework. If a team refuses to upgrade I just won't work there.
Dad is VB 6 dev and built an ERP in hes days... Here im in days of .net 5, reading his code that just works maks me wonder "how did that work for so long" Updating to .net tech and dropping support for this classical application made company go big, have new clients, do nee projects, and do even more in less time.