[HN Gopher] .NET 7 is Available Today
___________________________________________________________________
.NET 7 is Available Today
Author : dustedcodes
Score : 129 points
Date : 2022-11-08 16:11 UTC (6 hours ago)
(HTM) web link (devblogs.microsoft.com)
(TXT) w3m dump (devblogs.microsoft.com)
| ram4jesus wrote:
| 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 wrote:
| 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.
| dangus wrote:
| 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.
| kcb wrote:
| Unfortunately in some industries continuous delivery is
| literally illegal. Anyway there's a real issue with their
| current schedules. Let's say you're developing software some
| time in the middle of next year. There's effectively no LTS
| release available at all.
| phillipcarter wrote:
| The answer is to fix your processes, not demand Microsoft
| accommodate them. The lifecycles are already plenty long.
| to11mtm wrote:
| My issue is the cadences are difficult to work with.
|
| Microsoft's general-ish LTS for .NET is 2 years. We also
| only seem to get a new release every 2 years. It's hard
| to handle breaking changes between two versions quickly.
| kcb wrote:
| Any way you look at it 3 years is pretty low for industry
| standard LTS lifecycles. Besides the .NET Framework
| comparison Java LTS is 5-8 years.
| TillE wrote:
| We're not talking about "continuous delivery", this is just
| having a plan to ship updates every two years, on a well
| defined schedule. If you can't manage that
| organizationally, there are deeper problems.
|
| It's not really Microsoft's job to work around your awkward
| requirements. Everything is open source, you can ship
| patches for .NET 6 yourself if you really want to.
| AtNightWeCode wrote:
| 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.
| kcb wrote:
| .NET Standard is for libraries only.
| phillipcarter wrote:
| 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.
| [deleted]
| [deleted]
| simplotek wrote:
| > 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.
| to11mtm wrote:
| You may have gotten particularly lucky.
|
| I say particularly, because Core2->Core3.1 was a fairly
| painful change for some.
|
| I'd say the 66% worst case is 'you also have to add some
| compat flags and stories to properly resolve the compat
| flags'.
| colejohnson66 wrote:
| 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...
| Arnavion wrote:
| Bundling the framework doesn't solve the problem of said
| framework being old and unsupported because it wasn't LTS.
| Jwarder wrote:
| Seems like it makes the problem worse because you are then
| tied to a specific version at time of publishing and need
| to republish to get any framework patches.
|
| https://learn.microsoft.com/en-
| us/dotnet/core/deploying/runt...
| foepys wrote:
| Indeed. Microsoft identified this as a problem as well
| and pushes .NET security patches via Windows Update
| nowadays. When using self-contained apps, you won't get
| these patches.
| easton wrote:
| .NET Core security patches aren't pushed via Windows
| Update, only .NET Framework (since it's built into
| Windows). Unless something changed recently?
| vel0city wrote:
| You missed how there effectively isn't a .NET Core/.NET
| Framework delination anymore. It is just .NET, and .NET
| gets security patches from Windows Update.
| Kukumber wrote:
| 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 wrote:
| 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.
| None4U wrote:
| I have used NativeAOT before, and it does not enforce static
| linking. "no dynamic loading of arbitrary assemblies" refers
| to .NET assemblies, not the native dynamic link libraries
| they are compiled (using NativeAOT) to
| yread wrote:
| Is there a difference between static or dynamic linking for
| LGPL?
| TingPing wrote:
| Yes. The point of LGPL in concept is there is a clear
| boundary where you can modify and replace code. You can't
| replace a statically linked library.
| colejohnson66 wrote:
| Yes. Because dynamic linking happens at runtime, the DLL/so
| file can be replaced by a downstream user. Static linking
| does not allow the user access to that "freedom", so the
| whole binary becomes "infected" and must be open sourced.
| By enforcing a "user replaceable" boundary, the users'
| freedoms/rights to modify the open-source library are
| unaffected.
|
| Side note: how does that fit in with cryptographic
| signatures? GPL v3 was written to combat "Tivoization"
| (open source, but can't replace the binary). Does the LGPL
| v3 disallow such things with DLL/so files (use hashes to
| prevent replacing the FOSS lib)?
| cmeacham98 wrote:
| Straight from the LGPLv3: "A suitable mechanism is one
| that (a) uses at run time a copy of the Library already
| present on the user's computer system, and (b) will
| operate properly with a modified version of the Library
| that is interface-compatible with the Linked Version."
| OkayPhysicist wrote:
| The LGPL's boundary between your application and the
| licensed library requires that the end user have some way
| of substituting the LGPL library. So if your project is not
| at least source-available enough for the end user to
| recompile it with a modified version of the LGPL library,
| you're going to have a hard time meeting that requirement
| with static linking. More common is to just dynamically
| link to the LGPL library, which provides the substitution
| mechanism by its very nature.
| sylens wrote:
| 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
| CharlieDigital wrote:
| This was the first thing I tried out this morning and
| apparently it is not meant to work with ASP.NET (Web API in
| this case) and only for console applications.
|
| Explains why my container got stuck packaging Kestrel this
| morning.
| jp0d wrote:
| I was chatting with the devs at my company and they've just
| migrated their code to .Net 6!
___________________________________________________________________
(page generated 2022-11-08 23:01 UTC)