.NET 6 is now in Ubuntu 22.04
301–310 of 351 posts
Re: .NET 6 is now in Ubuntu 22.04
#302Earlier quoted context omitted.
Also, proper High DPI support in both WinForms and WPF in .NET 5+. There is starting to be a very notable difference there between applications compiled on .NET Framework (or VB6) versus those recompiled for .NET 5+ WinForms/WPF with older apps not just looking dated, but sometimes aggravatingly unusable/inaccessible on modern monitors.
I don't think I've ever seen a WPF app broken on hi-DPI, and I use a 4K display with 225% scaling. It was designed from grounds up as resolution-independent.
Re: .NET 6 is now in Ubuntu 22.04
#303Earlier quoted context omitted.
Sorry, I just can't see the change Satya brought to the company. Considering their "collaboration" with Canonical, it feels like Microsoft is paying Canonical in order to get help for strangling Linux desktop inside the Windows ecosystem, finally extinguishing desktop Linux installs once and for all. As a payback they're leaving server space to Canonical, but port their software to work on Ubuntu, so they have a suit…
> Sorry, I just can't see the change Satya brought to the company. I would say that if that is your perspective, then you probably didn't have a close up view of them and how they operated before and after. There's been a lot of spilled ink about it; I won't rehash it here. > it feels like Microsoft is paying Canonical in order to get help for strangling Linux desktop inside the Windows ecosystem, finally extinguishi…
I have witnessed "before" enough, so I distanced myself from them pretty sharply, and I didn't bother to check "after" that close. It's my fault, I accept it, but from this distance the end result doesn't show any meaningful differences. So, it's something to ponder if you ask me.
> Desktop Linux isn't likely to be something MSFT spends any amount of time concerning themselves with as competition.
It's may not be competition, but is a big hurdle against locking down PC ecosystem and converting them to appliances. If they can run all Linux apps under Windows, they can revoke all 3rd party signing keys, make Secure Boot mandatory and tell judges "See, it all works under Windows. We're no monopoly. We already ship the environment free with new PCs, anyway."
This stance against Microsoft is one of the rare firmly held strong opinions of mine. I certainly would prefer not hold this so firmly, but they made it impossible over the years.
Re: .NET 6 is now in Ubuntu 22.04
#304Earlier quoted context omitted.
You should clarify which country you recruit in/for, because these things can vary a great deal between different markets.
Australia.
Re: .NET 6 is now in Ubuntu 22.04
#305The .NET ecosystem is giving me a lot of confidence these days. I've been on this rollercoaster since .NET Core 2.x and don't think I will be getting off any time soon. We recently upgraded from 3.1 to 6, which was a total non-event. The code base that was around for Core 2.x is still the same one we have today. Some substantial changes made to the web interfaces and hosting, but nothing in the business logic or data…
Do you use ASP.NET Core Identity or roll your own auth? The thing that bugged me about ASP.NET Core Identity when I looked in late 2020 was that it stores too much info in the cookie itself. So if a user logs in, and then their authorization details change, the cookie could become stale. I've come around to the conclusion that the cookie should just be an opaque identifier pointing to a database record on the server.…
Every client gets 256 bits of entropy cookies which uniquely identify their “device”. The server will then deal with this as required to guide auth flows.
Re: .NET 6 is now in Ubuntu 22.04
#306Tbh I'm surprised they haven't been acquired by Microsoft yet. They're clearly aiming straight for it.
I probably would do the same if I were them, too.
Re: .NET 6 is now in Ubuntu 22.04
#307Earlier quoted context omitted.
For FreeBSD support, see the following issue for the porting effort. The community has been working like hell to make it happen since 2015 and at this point we have regular unofficial builds: https://github.com/dotnet/runtime/issues/14537 About 2 months ago they crushed hopes that official FreeBSD support will happen anytime soon by clearly stating that at this point, updating their Quality Assurance process to suppo…
> The FreeBSD ports system insists on requiring third party applications to be able to be built from source offline, while the .NET build process downloads packages left and right at various parts of the process. As someone who is not a part of the FreeBSD community, I just wanted to chime in to say that the FreeBSD Ports people are absolutely correct here, and that the build time behavior you describe is Bad Behavio…
Re: .NET 6 is now in Ubuntu 22.04
#308Question for the experienced .net folks - how is the dev experience of .net on linux vs .net on windows? Is it smooth or clunky? Pretty cool and interesting that a big linux vendor is on board with .net.
It depends a bit on what tools you use, but if you've jumped the ship from VS to VSC and mainly use the dotnet cli for things then there isn't much of a difference between platforms. If you're using VS, as in really use it and all it's feature, there is going to be a massive difference. That being said, I've used .Net and C# for over a decade and it's frankly just a clunky language and toolset. It's gotten better wit…
[0]: https://github.com/bflattened/bflat
Re: .NET 6 is now in Ubuntu 22.04
#309Earlier 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.
The implicitly assumption in the .NET choice is that dependencies may not be backwards compatible, so compile against a specific version and go ahead and ship that assembly in your self-contained deployment. Yes your packages are bigger, but disk space and bandwidth are cheaper than developer time and support costs.