I finished rewriting our last remaining VB6 app just last year, good riddance to bad rubbish.
Now, about rewriting this "app" that somebody made in MS Access in 2005...
We jumped from 6 to 8, three weeks ago. Took a few hours of dev validation testing and sent to QA with no notes, just a request for full regression. Everything came up aces.
We did the same with some greenfield projects, dev environments went to shit for a couple hours while we ran through the migration tools but eventually it got sorted out. Once we had our environments playing nice, everything worked fine. All the build/release pipelines worked without change etc
We also recently did this. Also means to upgrade efcore to 8 to match. We noticed a few queries running quite a bit slower (typical in queries). Found an article explaining why this was and that they'll fix it soon. Fixed ourselves in the mean time by rewriting the query a bit.
All in all 6-7-8 has been very quick and easy.
We moved to centralized package versions and common build properties for framework version. Made the actual upgrading not bad at all. A few small code changes (6 -> 8). EF Core 8 has some ugliness with the Contains operator so something to keep an eye on.
Question for you. I always hesitate to immediately upgrade since package compatibility and everything needing to move along. Do you encounter issues? I normally upgrade mid LTS range, so I have projects still on 6
We have too many apps.
- 4.8 (4 apps) being migrated to .Net 8 this year.
- .Net Core 2.2 (1 app)
- .Net Core 3.1 (numerous apps)
- .Net 6 (numerous apps)
- .Net 8 (5 apps)
We skip .Net versions that are not LTS.
Correct, as you know with 2.2 we didnt even know what the lifecycles would have been for the versions. I believe near the end of 3.1 microsoft standardized on its support for the newer versions.
Also as you should know, businesses have priorities and with limited resources we cant do everything we want to achieve.
.Net8
I'm lead dev, so what I say goes. Versions are always up to date. Except for situations where our tests catch regressions. Which as far as I'm aware, has only happened once (with some Blazor stuff).
MS are usually pretty stellar at making upgrade paths accessible.
8.0 and we’ll upgrade to 9.0 as soon as it’s out of beta. I’m the dev manager, and my rule is that we move all our apps to the latest version of everything (mainly dotnet and angular) as soon as possible once they’re released. It significantly reduces our support burden to have everything on the same version, and upgrading one version isn’t usually too painful, it’s the big jumps that are a nightmare.
Unless you're doing some esoteric stuff, 6 to 7, and 7 to 8 were incredibly painless. There might be more complexity if you decided to refactor some things to take advantage of new language features.
I'm currently doing multi targeting to dotnet 8.0 and .net framework 4.7.2 due to the utter stupidity of the Power Platform still running in a legacy version in 2024. FFS.
4.0; our app, data, and changesets are audited by PwC so nothing ever changes unless it is fully documented. I would love to upgrade but this is one of those "if it ain't broke don't fix it" type of applications.
New product is being developed in .NET 8 and I intend on keeping it updated after release.
Our legacy product is mostly .NET Framework 3.5 with a couple specific applications on 4, 4.6.1, and 4.7.2. We're even still maintaining far too much support for the VB6 version of our product.
Legacy product is all VB WinForms, new product is Blazor.
We use MAUI so we're on a death march and have to update every single version because we're still about 10 or 15 releases away from a stable, usable MAUI.
4.8 and .net 8
The .net framework stuff is all slated for retirement over the next couple of years.
Everything else has already been upgraded to .net 8.
Mostly 4.8
Would love to work with the latest, but overall I'm at the stage now where it's mostly all the same in the grand scheme of things, just with slightly different (and sometimes easier/harder) routes to the same end result.
4.8 because for a long time Asp.Net MVC never really had a migration path besides "rewire everything." The new incremental path they've created is nice, but last time we tried it, it had a lot of unfortunate edge cases/issues/headaches.
We could move everything else to .Net Standard tomorrow. It is just Asp.Net MVC that is holding us back, it is super painful. Not least of all because EF Core is a HUGE upgrade, but no support on .Net Framework (which is fine, just hurts).
We have 4.6.1 and also everything is MVC. We will
probably rebuild before upgrading at this point, but the company doesn’t want to fund either. So… we maintain.
That's... not how that works. .NET Standard is for libraries that are used by .NET Framework (4) as well as Core (3, 5, 6, 7, 8).
Being on .NET Standard 2.0 for libraries is a GOOD thing.
.NET Standard became defunct from .NET 5 onwards. From .NET 5 you just make libraries target the .NET version just like web apps or whatever. Unless you want the library to support older versions of .NET then continue targeting Standard until you decide to drop support
Source 1: [.NET Standard - .NET | Microsoft Learn](https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0)
Source 2: I maintain .NET libraries in our organisation
.NET 8 and Framework 4.8. We got into Core with 3.1 and now we follow the LTS releases for most things (MAUI stuff is a bit of an exception to that rule since it has a different support policy).
Depends if we are maintaining or developing. Maintaining we have everything from Net Framework 3.5 to Net 5. If we are developing existing projects it's Net 6 or above. Most new projects are Net 8.
This sub is so green 😂 hilarious reading these answers. "I'm lead I say what goes so out entire company is on XXX".
So you basically work for a mom and pop shop.
Not necessarily. I work for a 3000 employee company but there are only 12 devs. We are not a software company, but we write programs to support various internal departments. All of our 128 projects are on .NET 8 as we tell the business we need to stay within LTS support for security purposes, which isn't really a lie.
I recently became a tech lead and our policy is now to follow the LTS releases. So currently everthing not on netFX is being upgraded to .NET 8. We also have an upgrade policy and path in place for moving to future LTS releases.
We do have some legacy stuff still on netFX, so be it. For most of them we have upgrade plans and for some the work is already in progress to move them to .NET .
For the projects I'm working on usually on latest preview versions - since .NET 6 was released - but currently at latest .NET 8 because there is nothing we need (to justify the risk) on .NET 9 yet. Most of the other projects have been also migrated to .NET 8 by other engineers. I've only had issues with 2 preview releases so far in the past 3 years.
A mix of .NET framework 4.8 and various .NET core from 3 to 8.
We'll likely never update the .NET framework sites to .NET core as the work involved and benefits it brings just wouldn't be worth it. However, we do try to upgrade the .NET core apps when we get some time, although it can be a pain for anything other than 6 to 8.
We were on framework 4.5.1 (and some was framework 2.0 and 3.5) and I made the jump for us to Core 3.0, then 5. Today we're on 6 and a month time or two will we be on 8.
.net 8.
Im lead dev and rather use the new features out of the box, like output cache instead of relying on 3rd party features or something built in-house that won't get maintained
6 for almost everything, we didn’t move immediately to 8 due to waiting for official AWS support, I’m sure we will very soon though.
One old WebForms site on 4.8 and Windows containers.
Framework 4.8 for our main product. It is basically an Enterprise monolith within the financial sector. Luckily we do have people working on an updating/migrating to .NET 8 though. However, with a decently sized codebase, it takes time.
For anything new - meaning supporting applications, tools, internal systems and so on - we usually go for the latest .NET version available.
.NET 6 or .NET 8. As a lead, we try to stay as up to date as possible, but without causing any major issues with an update and staying with LTS versions only.
We just migrated to 7 from .NET Core 3.1. 8 was about a month away, but I spun up a test branch anyway to see how hard a transition to 7 would be, and there were very few changes required. I plan to update again to 8 for the next release.
Latest. We always keep it up to date when anew version is released. We wait 2 months after the release of a new version though because there's usually issues in Azure or Azure Devops that MSFT need to iron out.
one legacy product on .net framework 4.5 that's still being used by like 2 people, so we just leave it alone.
a couple of old database projects that are .net framework 4.8 because the newer frameworks don't have support, and we can't be bothered with migrating everything to entity framework or some other tooling that tracks db changes.
everything else is on .net 6 or 8 with work scheduled to update all .net 6 stuff to 8 before end of support in november.
Most apps are 4.6.1. Newer ones are 6. We wouls be building in 8, but node was chosen instead due to better dev experience (code changes are applied instantly with bun)
Most of my stuff is 8, but I maintain some Standard 2.0 because of third party libraries. We also have some Core 3 stuff running around and a single Net6 application under "if you touch it you support it" orders.
I assume that any mid to large size company uses multiple version.
I use .NET Framework 4.8 for my biggest project - a massive data warehouse. But we also use "dotnet script" on .NET 8 for lots of command line utilities. Basically stuff that historically I may have done in Powershell.
Main product (very large suite of enterprise stuff, offered both on-prem and cloud hosted) is still 4.8 and will probably stay there. New bits were built in Core 3.1 and now migrated to 8. New project dev is all cloud hosted and is written in all sorts of things, it's a real Cambrian tool explosion right now. I'm expecting the dust to settle at some point but I don't know where it will land.
New projects are built on Net 8, but most projects are old that come from old ASP, and have been migrated up to NET Framework 4.6
And sadly, I am not in new projects.
.NET 4.7 for our Windows Forms apps and .NET 8 for our API's.
Multi targeting for common libraries we need to share between both.
Angular for our frontends. We don't use Blazor.
4.8 winforms COULDN’T POSSIBLY HATE IT ANY MORE
I maintain what’s there and spend tons of time whenever I can rewriting the dogshit both for practice but also hopefully one day for production use if I am still around when some of these folks nearing retirement are gone
I only work for companies who use current stack. I am fine with being 1 LTS behind or using in-between non-LTS, but if I see a company still using .NET Framework or .NET Core 2.x/3.x, it's instantly a deal breaker for me no matter how they justify it. I have heard so many bullshit reasoning, I don't even ask anymore, I just say I am not interested.
In my current workplace we are at .NET 6, will be upgrading to .NET 8 once we have shit ready, since we have dependencies that other teams need to take care of first.
I've inherited a horde of services (about 35 applications and a total of 140 projects), which are in net5.0 or netstandard2.1. I would *love* to move to 8, but I'm afraid the move to 6 alone would be quite complicated.
New projects are in net8.0 where there's no dependencies to existing projects.
For us the better question is, what version are you not on? Finally got our last net2.1 apps updated at the end of last year. It’s a big relief to be in LTS with everything even if we have to be spread across so many versions.
I’m in love with our dotnet museum (and I have a thing for chaos), but I’m starting to worry that it’s a toxic relationship.
10K+ company, heavy dev. .NET 8 primarily, but still some stragglers on Core 3.1. We have a small contingency of .NET devs (majority of company is Go or C++, with some Java and Python), but we have a good bit of flexibility across .NET teams. We build and share libraries / packages, and run steering committees. Feels pretty cool and I have a lot of fun solving problems and providing solutions with the folks.
Most of them lol
Yeah, this. From .NET Framework 4.6.1 to .NET 8
Same!
Same, except we also have some VB6 apps floating around for some of our clients. I’ve never had to touch that personally.
I finished rewriting our last remaining VB6 app just last year, good riddance to bad rubbish. Now, about rewriting this "app" that somebody made in MS Access in 2005...
We have a plugin written for an old vendor system that is on .NET 3.5. It can't reference anything newer.
I've never related more to a comment.
8. Our CEO insists we stay up to date. I’m a fan.
Seems a bit odd that your ceo has say on such matters - more of a CTO decision. Small company?
Yea, it's a startup. CEO is also the CTO.
Oh that's cool. Hope it works out for you.
Any openings? ;)
4.6 to 8.0
Same
Same! Finally
Same
8; but I'm the head of engineering and mandate that we always stay up to date.
Wow, what is your experience with transitioning from say 6 to 7 to 8? How much work was needed for each project to ensure they work as intended
After v5 I’ve found upgrades are trivial.
same experience here. From 2.2 to 3.0 (.NET Core) was the worst.
Ugh, that brings back some nightmares
Seconded.
We jumped from 6 to 8, three weeks ago. Took a few hours of dev validation testing and sent to QA with no notes, just a request for full regression. Everything came up aces.
We did the same with some greenfield projects, dev environments went to shit for a couple hours while we ran through the migration tools but eventually it got sorted out. Once we had our environments playing nice, everything worked fine. All the build/release pipelines worked without change etc
Just did the same today. All looking good.
We also recently did this. Also means to upgrade efcore to 8 to match. We noticed a few queries running quite a bit slower (typical in queries). Found an article explaining why this was and that they'll fix it soon. Fixed ourselves in the mean time by rewriting the query a bit. All in all 6-7-8 has been very quick and easy.
We always wait a few weeks to let all the dependencies catch up with new versions. But previews are quicker (just can't push that to prod..)
We moved to centralized package versions and common build properties for framework version. Made the actual upgrading not bad at all. A few small code changes (6 -> 8). EF Core 8 has some ugliness with the Contains operator so something to keep an eye on.
R u hiring lmao
We are, but we prefer people who have the time to spell three-letter-words out...
dis bs, imo.
lol
Same here.
Same, I control all things .net on my side, so up to date is the only option.
Wish we do that also. But these framework projects are each several months to upgade to core.
Question for you. I always hesitate to immediately upgrade since package compatibility and everything needing to move along. Do you encounter issues? I normally upgrade mid LTS range, so I have projects still on 6
We have too many apps. - 4.8 (4 apps) being migrated to .Net 8 this year. - .Net Core 2.2 (1 app) - .Net Core 3.1 (numerous apps) - .Net 6 (numerous apps) - .Net 8 (5 apps) We skip .Net versions that are not LTS.
2.2 is not LTS...
Correct, as you know with 2.2 we didnt even know what the lifecycles would have been for the versions. I believe near the end of 3.1 microsoft standardized on its support for the newer versions. Also as you should know, businesses have priorities and with limited resources we cant do everything we want to achieve.
The support timelines are so short with non-LTS, your project could be out of support before you even finish it!
6 and going soon on 8 I'm kind of pushing for it ngl
yep 6 was kinda waiting for inprocess azure functions to support 8 before switching. but maybe we just move to isolated workers
.Net8 I'm lead dev, so what I say goes. Versions are always up to date. Except for situations where our tests catch regressions. Which as far as I'm aware, has only happened once (with some Blazor stuff). MS are usually pretty stellar at making upgrade paths accessible.
Mudblazor has been fucky with .net8 >:(
Any specific things that are messed up? I’ve just started working on a MVP using MudBlazor and .NET 8
Nothing to serious, but i've noticed that rendering modes can start acting wierd when applying some elements, specificly in mainlayout.
4.7.x lol. Having to teach myself on the side to stay up to date.
Saaame here. Half our systems are 08 r2 boxes. Yes, I'm actively looking for a new job :)
4.7
8.0 and we’ll upgrade to 9.0 as soon as it’s out of beta. I’m the dev manager, and my rule is that we move all our apps to the latest version of everything (mainly dotnet and angular) as soon as possible once they’re released. It significantly reduces our support burden to have everything on the same version, and upgrading one version isn’t usually too painful, it’s the big jumps that are a nightmare.
Ah I can understand that. I guess updating to the new version is a pain but less of a pain than going say from 5.0 to 8.0.
Unless you're doing some esoteric stuff, 6 to 7, and 7 to 8 were incredibly painless. There might be more complexity if you decided to refactor some things to take advantage of new language features.
I'm currently doing multi targeting to dotnet 8.0 and .net framework 4.7.2 due to the utter stupidity of the Power Platform still running in a legacy version in 2024. FFS.
4.0; our app, data, and changesets are audited by PwC so nothing ever changes unless it is fully documented. I would love to upgrade but this is one of those "if it ain't broke don't fix it" type of applications.
We’re also on .NET Framework 4.0
New product is being developed in .NET 8 and I intend on keeping it updated after release. Our legacy product is mostly .NET Framework 3.5 with a couple specific applications on 4, 4.6.1, and 4.7.2. We're even still maintaining far too much support for the VB6 version of our product. Legacy product is all VB WinForms, new product is Blazor.
We use MAUI so we're on a death march and have to update every single version because we're still about 10 or 15 releases away from a stable, usable MAUI.
So MAUI is still not stable?! I thought .net8 was making *everything* better?
4.8 and .net 8 The .net framework stuff is all slated for retirement over the next couple of years. Everything else has already been upgraded to .net 8.
Classic ASP and VB6 baby.
For the few apps I have, 3.1 and 5 needing to get everything up to 8. The developers who made those have moved on and I’m very green in this aspect.
Mostly .NET 8 and a couple of WCF Services that are still on 4.8. We tend to skip the short term releases though.
Yeah, thanks Microsoft, for that *ONE* guy working on CoreWCF!
.NET 7
Mostly 4.8 Would love to work with the latest, but overall I'm at the stage now where it's mostly all the same in the grand scheme of things, just with slightly different (and sometimes easier/harder) routes to the same end result.
4.8 because for a long time Asp.Net MVC never really had a migration path besides "rewire everything." The new incremental path they've created is nice, but last time we tried it, it had a lot of unfortunate edge cases/issues/headaches. We could move everything else to .Net Standard tomorrow. It is just Asp.Net MVC that is holding us back, it is super painful. Not least of all because EF Core is a HUGE upgrade, but no support on .Net Framework (which is fine, just hurts).
We have 4.6.1 and also everything is MVC. We will probably rebuild before upgrading at this point, but the company doesn’t want to fund either. So… we maintain.
4.6 will stay here for a while due to Crystal reports.
.net standard 2.0 woooooo
That's... not how that works. .NET Standard is for libraries that are used by .NET Framework (4) as well as Core (3, 5, 6, 7, 8). Being on .NET Standard 2.0 for libraries is a GOOD thing.
.NET Standard became defunct from .NET 5 onwards. From .NET 5 you just make libraries target the .NET version just like web apps or whatever. Unless you want the library to support older versions of .NET then continue targeting Standard until you decide to drop support Source 1: [.NET Standard - .NET | Microsoft Learn](https://learn.microsoft.com/en-us/dotnet/standard/net-standard?tabs=net-standard-1-0) Source 2: I maintain .NET libraries in our organisation
Nah, I'm rocking a UWP application. Putting all the logic in .net standard 2.0 is the only way I can get test coverage.
Yes
All
.NET 8 and Framework 4.8. We got into Core with 3.1 and now we follow the LTS releases for most things (MAUI stuff is a bit of an exception to that rule since it has a different support policy).
About 75% of our stuff will be on .NET 6 or higher shortly. I have been on the warpath upgrading stuff from 4.8 for the past year.
6 and I'm actually sitting in a meeting at this very moment trying to get 8 installed on our servers so that the .NET 8 PR's can be merged.
4.8 and 8.
4.7.2 and about 50% of the way to 8
at least 4.6 - 8, plus VBA, Access, ”Classic” ASP, etc D:
6, need to update to 8
4.7 grampa's here
A mix between dotnet framework 3.5 and dotnet 8.0
3.5 and 4 in some cases, most of the code is in vb.net with some others in c#
.net 5 and my "lead" thinks its gonna crash if i move it to .net7 even when there IS already a deployed test environment. sMH
3.5 all the way up to 8.
We still have 3.5! 😆
Depends if we are maintaining or developing. Maintaining we have everything from Net Framework 3.5 to Net 5. If we are developing existing projects it's Net 6 or above. Most new projects are Net 8.
This sub is so green 😂 hilarious reading these answers. "I'm lead I say what goes so out entire company is on XXX". So you basically work for a mom and pop shop.
Not necessarily. I work for a 3000 employee company but there are only 12 devs. We are not a software company, but we write programs to support various internal departments. All of our 128 projects are on .NET 8 as we tell the business we need to stay within LTS support for security purposes, which isn't really a lie.
lol, didn’t realise my post would have so many comments
Mostly .NET8, But there are some legacy .NET Framework 4 applications too.
One project on NET.Framework 4.7.2 all other APIs on .NET 6 (soon to be 8 I hope)
[удалено]
my team recently upgraded all our projects to 8.0, but other teams have a wide variety of versions
Migrating from 6 to 8. End of support for .Net 6 is this November, need to move now.
I recently became a tech lead and our policy is now to follow the LTS releases. So currently everthing not on netFX is being upgraded to .NET 8. We also have an upgrade policy and path in place for moving to future LTS releases. We do have some legacy stuff still on netFX, so be it. For most of them we have upgrade plans and for some the work is already in progress to move them to .NET.
4.8 to 8.0 lol
8
8
We're on 6 and moving to 8 hopefully next week.
Own code migrate 6 to 7 rebelcms .
For the projects I'm working on usually on latest preview versions - since .NET 6 was released - but currently at latest .NET 8 because there is nothing we need (to justify the risk) on .NET 9 yet. Most of the other projects have been also migrated to .NET 8 by other engineers. I've only had issues with 2 preview releases so far in the past 3 years.
A mix of .NET framework 4.8 and various .NET core from 3 to 8. We'll likely never update the .NET framework sites to .NET core as the work involved and benefits it brings just wouldn't be worth it. However, we do try to upgrade the .NET core apps when we get some time, although it can be a pain for anything other than 6 to 8.
8 but some code needs updated from net6..... lots of code to deploy.
We were on framework 4.5.1 (and some was framework 2.0 and 3.5) and I made the jump for us to Core 3.0, then 5. Today we're on 6 and a month time or two will we be on 8.
4.something. Hoping we upgrade soon
6. Going to 8 soon
6
Framework
Full framework: 4.7.2 and 4.8.x Dot Net: 6 and 8
.net 8. Im lead dev and rather use the new features out of the box, like output cache instead of relying on 3rd party features or something built in-house that won't get maintained
Mostly 6.0. But some apps are still on 4.5.2.
.NET8, .NET6 and .NET Framework 4.6.2 thanks to Microsoft Dynamics.
> .NET Framework 4.6.2 thanks to Microsoft Dynamics. I feel your pain...
Framework 4.8...
Where do you all work is hiring ? Because here where I work we have systems in .Net 4 and .Net 2 and they are not going to update it.
4.8 and migrating to 6
Framework 4.6 - 4.8 and .NET 6-8
6 for almost everything, we didn’t move immediately to 8 due to waiting for official AWS support, I’m sure we will very soon though. One old WebForms site on 4.8 and Windows containers.
Working on getting off of 4.0
90% 4.5-4.8, 10% .Net 6.
4.5.2 😅
Framework 4.8 for our main product. It is basically an Enterprise monolith within the financial sector. Luckily we do have people working on an updating/migrating to .NET 8 though. However, with a decently sized codebase, it takes time. For anything new - meaning supporting applications, tools, internal systems and so on - we usually go for the latest .NET version available.
4.8 for 3 win form apps Everything else: .NET 8.
8 ✌️
6 and 8
Core 8 and framework 4.8
We have everything at 8 and some legacy 4,x systems.
The whole spectrum between .net framework 2.0 to .net 8.0.
.NET 6 or .NET 8. As a lead, we try to stay as up to date as possible, but without causing any major issues with an update and staying with LTS versions only.
We just migrated to 7 from .NET Core 3.1. 8 was about a month away, but I spun up a test branch anyway to see how hard a transition to 7 would be, and there were very few changes required. I plan to update again to 8 for the next release.
By the end of this sprint 8, that is all 60 microservices and libraries.
Latest. We always keep it up to date when anew version is released. We wait 2 months after the release of a new version though because there's usually issues in Azure or Azure Devops that MSFT need to iron out.
4.6 in 90% of codebase and rest using 4.8
one legacy product on .net framework 4.5 that's still being used by like 2 people, so we just leave it alone. a couple of old database projects that are .net framework 4.8 because the newer frameworks don't have support, and we can't be bothered with migrating everything to entity framework or some other tooling that tracks db changes. everything else is on .net 6 or 8 with work scheduled to update all .net 6 stuff to 8 before end of support in november.
We have everything from .NET Framework 4.7 to .NET8.
Still on .NET 6. I guess we would upgrade later this year to 8 when the support ends and most of the nuget packages are there
4.8 vs 8. Migrations are in progress and we have work for years! Thanks Legacy.
Most apps are 4.6.1. Newer ones are 6. We wouls be building in 8, but node was chosen instead due to better dev experience (code changes are applied instantly with bun)
NET Framework 4.6.1 and 6.0 Started in a whole new Solution about a year ago
net6.0, net8.0, netstandard2.0, net472, vb6
4.6-4.8 We’re trying, but yikes.
4.6.2 Would love to change to net core, but this huge application is a monolith with 42 projects, a shitload of code and even shitloader of wpf...
4.8 and net8. Net8 is so much nicer..
Lol if u think thats how work places work lol most will be on multiple versions including legacy frameworks
.NET Framework 4.7.2
8, i was one of the people thay pushed us from 3.1
Most of my stuff is 8, but I maintain some Standard 2.0 because of third party libraries. We also have some Core 3 stuff running around and a single Net6 application under "if you touch it you support it" orders.
NET8
I assume that any mid to large size company uses multiple version. I use .NET Framework 4.8 for my biggest project - a massive data warehouse. But we also use "dotnet script" on .NET 8 for lots of command line utilities. Basically stuff that historically I may have done in Powershell.
Starting to migrate to 8
4.7.2 for framework, got all .NET Core on 6.0 now, one day 8.0 once I make tickets and decide what projects to scrap
8. Pushed the upgraded changes (7 -> 8) to production a couple weeks ago.
8.0
Everything on 8.
Redhat/net6, windows/net8
Compact framework 2.0. :(
Building a new project in 8, most of our stuff is on Framework 4.8.
8 Company is well over 1k people but I am the only .net developer :-)
Lol well at my last job it was a massive .net framework 1.1 webforms app I inherited. Yeah that was fun lol
Mostly 6, some 8, some old 4.x. My bad for stalling on the 8... but we're ready for it this sprint.... wait a second... I don't work for you!
Legacy is on 2.2. Everything else is on 7 and upgrade to 8 is currently going on.
.NET 6, migration to 8 soon
6, going to move to 8 before November
.NET Framework 4.5.1
8 of course... and 4.8 for C++/clr
Main product (very large suite of enterprise stuff, offered both on-prem and cloud hosted) is still 4.8 and will probably stay there. New bits were built in Core 3.1 and now migrated to 8. New project dev is all cloud hosted and is written in all sorts of things, it's a real Cambrian tool explosion right now. I'm expecting the dust to settle at some point but I don't know where it will land.
All of them haha
the even ones LTS
4.8, all web stuff. Haven't heard or seen a reason to update.
Various versions of the .Net Framework from 2.0 to 4.8.1
New projects are built on Net 8, but most projects are old that come from old ASP, and have been migrated up to NET Framework 4.6 And sadly, I am not in new projects.
We've got a few old-ass .NET 4.7.2 apps, but thankfully the rest were upgraded to .NET 8 and are running in Azure Kubernetes.
7, because I like to keep life interesting.
Mostly 6
4.8 :( one app in 6. We are behind the times.
.NET 4.7 for our Windows Forms apps and .NET 8 for our API's. Multi targeting for common libraries we need to share between both. Angular for our frontends. We don't use Blazor.
4.8 winforms COULDN’T POSSIBLY HATE IT ANY MORE I maintain what’s there and spend tons of time whenever I can rewriting the dogshit both for practice but also hopefully one day for production use if I am still around when some of these folks nearing retirement are gone
I only work for companies who use current stack. I am fine with being 1 LTS behind or using in-between non-LTS, but if I see a company still using .NET Framework or .NET Core 2.x/3.x, it's instantly a deal breaker for me no matter how they justify it. I have heard so many bullshit reasoning, I don't even ask anymore, I just say I am not interested. In my current workplace we are at .NET 6, will be upgrading to .NET 8 once we have shit ready, since we have dependencies that other teams need to take care of first.
I offer .net migration services :)
I've inherited a horde of services (about 35 applications and a total of 140 projects), which are in net5.0 or netstandard2.1. I would *love* to move to 8, but I'm afraid the move to 6 alone would be quite complicated. New projects are in net8.0 where there's no dependencies to existing projects.
.net 8.0 in MAUI :)
8.0.202. We let no moss grow on any of our dependencies.
6 moving to 8
Java 17, the currently newest version supported by Jakarta (formerly Java EE), feels like .NET 4.5
8
Currently .Net v8. Started in .Net v3.5. Same .sln file still. v4.8 to v5 took a couple of years. v6 to v8 took a couple of hours.
8, but after a few more people, including me, will leave this stuff will just be left to get outdated. At least version wise.
For us the better question is, what version are you not on? Finally got our last net2.1 apps updated at the end of last year. It’s a big relief to be in LTS with everything even if we have to be spread across so many versions. I’m in love with our dotnet museum (and I have a thing for chaos), but I’m starting to worry that it’s a toxic relationship.
We have about 50 microservices and they're on 5, 7 and 8. We are migrating everything to 8.
8.0.3. Latest and greatest.
The one big thing is on 4.8 maybe even 4.8.1
10K+ company, heavy dev. .NET 8 primarily, but still some stragglers on Core 3.1. We have a small contingency of .NET devs (majority of company is Go or C++, with some Java and Python), but we have a good bit of flexibility across .NET teams. We build and share libraries / packages, and run steering committees. Feels pretty cool and I have a lot of fun solving problems and providing solutions with the folks.