They really need to extend the support time for their LTS releases. Sure, if you're developing a SaaS you can stay on top of .NET versions but it's definitely causing friction for enterprise and slow moving regulated software. .NET Framework 4.5.2 was supported for 8 years in comparison.
We're about to start a project with those limitations and there really is no good choice now that .NET 6 is already a year through it's lifecycle.
If, when publishing your app, you choose the "self-contained" mode (as opposed to "framework dependent")[a], the runtime will be bundled with your program into the executable. Then you don't need to worry about updating your client's OS. My work is using it for deployment to Linux, and it works great.
> Sure, if you're developing a SaaS you can stay on top of .NET versions but it's definitely causing friction for enterprise and slow moving regulated software.
You have a point, but I'd call out that migrating to newer releases can and often is trouble-free.
A couple of months ago I worked on a .NET Core 2 web service that was put on cold storage for a few years, and all it took to migrate it to .NET Core 6 was a few version number bumps and a rebuilding the project.
YMMV of course, but LTS shelf life might not be a deal breaker.
What limitations are involved? I’ve never really understood why 3 years is unacceptable or intractable. In nearly every case the real issue is that nobody wants to fix broken internal processes that prevent people from upgrading once a decade.
There isn't any functional difference between a 3 year or 5 year or 8 year support cycle. The only two development modes for a service are – build once and maintain occasionally, or build once and leave untouched forever. Those in the first set will be fine with 3 years of support. Those in the second will always ask for more time no matter what the deadline is.
I agree that LTS should last longer. They made it easier to upgrade between versions though. Perhaps won't help you if you use .NET in patient critical medtech for instance (in EU).
Biggest problem for us is .NET Standard. I don't even understand how it could work on a theoretical level. Maybe it could work if there was no dependencies.
We're in the process of migration a large MVC application from Framework 4.8 to .NET 6. It's been....painful. Hopefully at least for a while updating to new LTS versions will be less so.
NativeAOT is one of the most important feature C# needed, very nice that it is finally coming, i still can't believe it took them this long
Congrats to everyone who fought vigorously to make it happen, screw the managers, execs and their surrounding noise, long live to the real engineers at Microsoft
- "All required code is compiled and/or linked into the executable, ..."
- "No JIT means no dynamic loading of arbitrary assemblies ..."
- "... with everything compiled and linked into the app ..."
This sounds very much like static linking, possibly with no option of dynamic linking/loading of code.
Presumably this would have implications for those using LGPL-licensed .NET libraries, especially those who'd like to distributed closed-source applications AOT-compiled using this approach?
Are there any commonly-used .NET libraries these days that are only LGPL-licensed?
I haven't done .NET development in a decade, so I don't really know the current state of affairs.
Seems like the only reasons for upgrading from 6 to 7 would be an easier path (possibly) to upgrade later than going from 6 to 8, or if you really want to use something in c# 11 (https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...) . I remain unconvinced...
If you are using `time` and calculate the time from application startup to exit 0 then it is not representative of performance of the code itself - more aggressive optimization in JIT tend to have increasing cost with each release even if the people working on it try to always ensure the compilation throughput stays constant and we get more optimized JIT code per same amount of CPU work.
If you would like to have representative benchmark data, I suggest relying on BenchmarkDotNet instead.
Upgrades are honestly really easy, and have been since around .NET Core 2.
I have now done 2 -> 2.1 -> 2.2 -> 3 -> 3.1 -> 5 -> 6 with very little friction at all, in a fairly big web API codebase.
I don't foresee any issues going from 6 -> 7. 5 -> 6 was essentially just a find and replace on TargetFramework and it all just worked.
I love Java. And I'm working on c# right now at my job and I'm loving it too. This is happy news for me. When my enterprise finally adopts it 4 years from now. D:
[+] [-] kcb|3 years ago|reply
We're about to start a project with those limitations and there really is no good choice now that .NET 6 is already a year through it's lifecycle.
[+] [-] colejohnson66|3 years ago|reply
[a]: Pass the `--sc true` option to `dotnet publish`: https://learn.microsoft.com/en-us/dotnet/core/tools/dotnet-p...
[+] [-] simplotek|3 years ago|reply
You have a point, but I'd call out that migrating to newer releases can and often is trouble-free.
A couple of months ago I worked on a .NET Core 2 web service that was put on cold storage for a few years, and all it took to migrate it to .NET Core 6 was a few version number bumps and a rebuilding the project.
YMMV of course, but LTS shelf life might not be a deal breaker.
[+] [-] phillipcarter|3 years ago|reply
[+] [-] paxys|3 years ago|reply
[+] [-] dangus|3 years ago|reply
Until the date hits them in the face there’s no urgency.
[+] [-] AtNightWeCode|3 years ago|reply
Biggest problem for us is .NET Standard. I don't even understand how it could work on a theoretical level. Maybe it could work if there was no dependencies.
[+] [-] vraylle|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] unknown|3 years ago|reply
[deleted]
[+] [-] Kukumber|3 years ago|reply
Congrats to everyone who fought vigorously to make it happen, screw the managers, execs and their surrounding noise, long live to the real engineers at Microsoft
[+] [-] VancouverMan|3 years ago|reply
Presumably this would have implications for those using LGPL-licensed .NET libraries, especially those who'd like to distributed closed-source applications AOT-compiled using this approach?
Are there any commonly-used .NET libraries these days that are only LGPL-licensed?
I haven't done .NET development in a decade, so I don't really know the current state of affairs.
[+] [-] sylens|3 years ago|reply
[+] [-] pjmlp|3 years ago|reply
NGEN, Singularity and Midori research (whose tech landed on Windows 8 MDIL and UWP .NET Native respectively), Mono AOT.
I always were the opinion that given Anders Hejlsberg background, .NET 1.0 should have had a better AOT story than NGEN.
[+] [-] animitronix|3 years ago|reply
Seems like the only reasons for upgrading from 6 to 7 would be an easier path (possibly) to upgrade later than going from 6 to 8, or if you really want to use something in c# 11 (https://learn.microsoft.com/en-us/dotnet/csharp/whats-new/cs...) . I remain unconvinced...
[+] [-] AlfeG|3 years ago|reply
In our case improved hit reload is very welcome. So I guess we will incremenet our runtime.
[+] [-] EVa5I7bHFq9mnYK|3 years ago|reply
5 1107ms
6 1075ms
7 1211ms
Just number crunching and calling HashSet.
[+] [-] neonsunset|3 years ago|reply
If you would like to have representative benchmark data, I suggest relying on BenchmarkDotNet instead.
[+] [-] Izikiel43|3 years ago|reply
[+] [-] jp0d|3 years ago|reply
[+] [-] joshschreuder|3 years ago|reply
I don't foresee any issues going from 6 -> 7. 5 -> 6 was essentially just a find and replace on TargetFramework and it all just worked.
[+] [-] ram4jesus|3 years ago|reply
[+] [-] Iwan-Zotow|3 years ago|reply
[+] [-] delneg|3 years ago|reply
[+] [-] unknown|3 years ago|reply
[deleted]