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
.NET 6 is now in Ubuntu 22.04
311–320 of 351 posts
Re: .NET 6 is now in Ubuntu 22.04
#312Earlier 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…
Re: .NET 6 is now in Ubuntu 22.04
#313Earlier 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.
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
#314Earlier 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.
Re: .NET 6 is now in Ubuntu 22.04
#315A 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…
Re: .NET 6 is now in Ubuntu 22.04
#316Earlier 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.
Re: .NET 6 is now in Ubuntu 22.04
#317Earlier 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…
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
#318Meh. 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.
https://www.reddit.com/r/Minecraft/comments/vjpz2w/ingame_ch...
Fuck Microsoft.
Re: .NET 6 is now in Ubuntu 22.04
#319Earlier 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…
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.