Live data from Hacker News

.NET 6 is now in Ubuntu 22.04

devblogs.microsoft.com

311–320 of 351 posts

Re: .NET 6 is now in Ubuntu 22.04

#311
post #98

I've recently been working with a C# app that's based on a nearly out of support .net 3.X version I think. It's fully inherited from a tech partner, but we have free reign to modify it as needed. I was excited to try and port it from a Windows only older .net app to .net core 6, but unfortunately too much of it doesn't have a simple to port to equivalent in .NET 6 and it would require us to completely rewrite it. Thi…

SOAP as in WCF? If so then there is now a WCF port out now: https://github.com/CoreWCF/CoreWCF

More likely, SOAP as in ASP.NET (old one), which has been around since .NET 1.0. Few people remember these days, but the reason why .NET is called .NET is because it was pitched as "all about web services" back when XML and SOAP was the new hotness.

Re: .NET 6 is now in Ubuntu 22.04

#312
post #214

Earlier quoted context omitted.

I would advise against Blazor Server. In contrast to standard frontend SPA frameworks, Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state. I found that connection is easily/fequently disrupted resulting in an app reset, lost state, and poor user experience, to say nothing of the scalability implications. Though, for a purely back-of…

> Blazor Server requires a peristent websocket connection to each client to execute the C# code you write on the client and maintain state Blazor Server retains the circuit for up to 3 minutes if the connection is lost, so you do not loose the connection even if the websocket connection is interrupted. It is also not correct that it needs a websocket connection. It builds on SignalR which will use websockets if avail…

Especially on backgrounded browser tabs, users circuts were frequently lost. also People frequently multitask their activities. 3 minutes is nothing.

Re: .NET 6 is now in Ubuntu 22.04

#313
post #215

Earlier quoted context omitted.

I don’t think it would be wise for apt to repackage or recreate Nuget functionality. The initial install of dotnet should be done by apt, the packages should be handled by Nuget.

If you want to package an application which depends on a library, you have to package the library, too. This is the (pretty much sole) reason that distros package libraries. From a technical perspective it's pretty much a solved problem for any language ecosystem whose dependency management is reproducible, is uniform enough to support basic automation, and supports some measure of vendorization.

> If you want to package an application which depends on a library, you have to package the library, too.

You don't have to. You can package the application together with the right version of the library, as a single package.

Re: .NET 6 is now in Ubuntu 22.04

#314
post #60

Earlier quoted context omitted.

I would have expected .NET's core demographic to be mostly CentOS and RHEL users. But I imagine Microsoft really wants you to run your workloads in Azure instead of on-premise, and Ubuntu fits that model better.

>I would have expected .NET's core demographic to be mostly CentOS and RHEL users. Why? There is nothing "Enterprisey" about .NET Core. It's a perfect fit for both fast-moving startups and big enterprises.

The "enterprisey" part of .NET is the brand itself. It's well-established in the enterprise, less so outside of it.

Re: .NET 6 is now in Ubuntu 22.04

#315

A fully devoted Linux developer here that never touched Windows' ecosystem(.NET, Visual C++, win32 api, all those), any reason for me to jump on .NET? where does this runtime run(x86/windows, now linux, what about MacOS, and embedded systems), and what's the selling point(web framework in c++ like language? a better c++/java?) https://learnxinyminutes.com/docs/csharp/ it looks more like Java than c++ to me. On a diff…

It's broadly in the same ballpark as Java, but with more language features (e.g. sequence comprehensions, pattern matching), and it offers some low-level features like raw pointers and spans for when you want performance or interop with C.

Re: .NET 6 is now in Ubuntu 22.04

#316

Earlier quoted context omitted.

Australia.

Yup, Australia has a real hard on for C#. As a dev in Australia, I can support the list you gave, but I'd be cautious to extend that globally.

I'm from Europe and there's a lot of .NET jobs here too. In my experience, the US is the outlier with a very small .NET presence.

Re: .NET 6 is now in Ubuntu 22.04

#317
post #215

Earlier quoted context omitted.

If you want to package an application which depends on a library, you have to package the library, too. This is the (pretty much sole) reason that distros package libraries. From a technical perspective it's pretty much a solved problem for any language ecosystem whose dependency management is reproducible, is uniform enough to support basic automation, and supports some measure of vendorization.

IME (and I worked at Microsoft previously), Nuget and MSBuild have decided that application developers should have full control of their dependencies and that system administrators can override these things but not easily. I understand that distro-level package manager want to make it possible to upgrade a system library for all applications, but the .NET world isn’t going in that direction (yes yes I know about the…

Application developers can still pin their in-ecosystem library dependencies to exact versions and have downstream, distro-level package managers respect that while building everything from source and making the system package manager aware of all of those library versions in more or less the usual way. (That's how building Rust and Go applications already works on NixOS, for example.)

That's why I say it's largely a solved problem for language ecosystems that tick a few basic boxes.

Can't Nuget and MSBuild support this? Can they not dump lockfiles like common build tools for Rust, Go, Javascript, Haskell, Python, Nim, PHP, etc., do? Is there a general problem (like there is with Java) where actually building from source is so difficult that it is rarely done?

Anyway there's already a suite of Linux packaging options built around the kind of app distribution model Microsoft expects, and Canonical even has one of their own! I don't see why they wouldn't support distributing .NET applications as Snaps, or maybe even automating the creation of Snap packages for .NET applications.

Re: .NET 6 is now in Ubuntu 22.04

#318
post #89
post #34

Meh. In the end, Microsoft will betray those who trusted it. Long term, better just to pretend it does not exist and never, ever depend on anything with Microsoft name on it.

I knew there'd be at least one of you guys in this thread.

I've been keeping an eye on Microsoft's bullshit since the 90s. Just when you think that leopard might have changed its spots (think VS Code) they pull this shit:

https://www.reddit.com/r/Minecraft/comments/vjpz2w/ingame_ch...

Fuck Microsoft.

Re: .NET 6 is now in Ubuntu 22.04

#319
post #317

Earlier quoted context omitted.

IME (and I worked at Microsoft previously), Nuget and MSBuild have decided that application developers should have full control of their dependencies and that system administrators can override these things but not easily. I understand that distro-level package manager want to make it possible to upgrade a system library for all applications, but the .NET world isn’t going in that direction (yes yes I know about the…

Application developers can still pin their in-ecosystem library dependencies to exact versions and have downstream, distro-level package managers respect that while building everything from source and making the system package manager aware of all of those library versions in more or less the usual way. (That's how building Rust and Go applications already works on NixOS, for example.) That's why I say it's largely a…

There is no immediate problem with building from source, there simply isn't much of a benefit to doing so. An assembly compiled with different optimizing C# compilers will be virtually identical assuming the source files are identical. I can think of a reason not to compile from source: it's essentially statically linking code into your assembly which can be huge problem for middleware packages that want to override the specific version you depend on. This is very common with the JSON serialization library, which is highly backwards compatible.

I think historically in the .NET world, package consumers have expected pre-compiled assemblies and not source code and so that's what the ecosystem has developed around.

Post reply on HN