top | item 33520574

.NET 7 is Available Today

187 points| dustedcodes | 3 years ago |devblogs.microsoft.com

83 comments

order
[+] kcb|3 years ago|reply
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.

[+] colejohnson66|3 years ago|reply
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.

[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
> 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.

[+] phillipcarter|3 years ago|reply
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.
[+] paxys|3 years ago|reply
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.
[+] dangus|3 years ago|reply
Slow moving orgs with brittle release processes are going to miss support deadlines anyway, it doesn’t matter if they arrive sooner or later.

Until the date hits them in the face there’s no urgency.

[+] AtNightWeCode|3 years ago|reply
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.

[+] vraylle|3 years ago|reply
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.
[+] Kukumber|3 years ago|reply
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

[+] VancouverMan|3 years ago|reply
The article mentions things like:

  - "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.

[+] sylens|3 years ago|reply
Agreed, I feel like it was the missing piece from their .NET Anywhere story and am curious to see if it creates an uptick in adoption
[+] pjmlp|3 years ago|reply
While NativeAOT is to be praised, we should not forget all the avenues that came before it.

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
So if I'm reading https://dotnet.microsoft.com/en-us/platform/support/policy/d... correctly, 7 is an STA release and support for it will end before support for 6 (LTS release) ends?!

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
I guess You need net7 of You really need every bit of performance.

In our case improved hit reload is very welcome. So I guess we will incremenet our runtime.

[+] EVa5I7bHFq9mnYK|3 years ago|reply
Changed 6 to 7 in my project file, the program started running 10% slower ... hmm. Specifically,

5 1107ms

6 1075ms

7 1211ms

Just number crunching and calling HashSet.

[+] neonsunset|3 years ago|reply
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.

[+] Izikiel43|3 years ago|reply
Use benchmark.net for tests and come back
[+] jp0d|3 years ago|reply
I was chatting with the devs at my company and they've just migrated their code to .Net 6!
[+] joshschreuder|3 years ago|reply
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.

[+] ram4jesus|3 years ago|reply
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: