.NET 5.0

Post by ablekh » Wed, Nov 11, 2020, 4:16 AM UTC

kumarvvr wrote: post #347

ablekh wrote: post #340

Earlier quoted context omitted.

Thank you very much for sharing your DI experience. What is wrong with using IServiceProvider dependency? What is CTOR (hierarchy)?

CTOR heirarchy - Constructor Hierarchy. You have to have your constructors such that the ones needing a lot of services and in-turn those services needing a lot of other services need to be added to the service container and ensured to be instantiable. Essentially, you build a tree of your services and have to ensure that all your constructors have objects that can be instantiated or managed by the DI system.

Post by billyjobob » Wed, Nov 11, 2020, 4:46 AM UTC

aidenn0 wrote: post #236

iso8859-1 wrote: post #95

People who think this is actually cross-platform need to consider these points: * Debian can't package F# because it is built using MSBuild, and MSBuild is built using MSBuild. How can it be Microsoft doesn't have the resources to get it into a major distribution? * Microsoft won't commit to maintaining any cross-platform GUI libraries. You will be relying on some random community project. Compare this with e.g. Pyth…

How does bootstrapping work for other products in debian? GCC is built using GCC and cmucl is built using cmucl.

Post by FridgeSeal » Wed, Nov 11, 2020, 5:26 AM UTC

mattmanser wrote: post #310

FridgeSeal wrote: post #273

Earlier quoted context omitted.

> ASP.NET Core does push you strongly towards dependency injection, but it does not force you at all to use it. Their own documentation for making queries against SQL Server doesn't provide examples of how to do it that aren't using DI. "Just inject it" it just says. Thanks .net, super helpful. Maybe the docs are there, but I couldn't find them at all when I went looking.

using(var conn = new SqlConnection(" ")) using(var cmd = new SqlCommand(@"Query here", conn)) { conn.Open(); cmd.executeNonQuery(); }

Post by hackerfromthefu » Wed, Nov 11, 2020, 5:52 AM UTC

Longhanks wrote: post #159

soapdog wrote: post #135

Congratulations to the team but more than a year after the Surface Pro X shipped and there is still no way to build desktop applications for aarch64 using dotnet/vs2019 on the local machine. Windows on ARM has no native support for WPF, WinForms, or WinUI. Visual Studio 2019 running as x86 32bits application can't see the local machine as a target for aarch64 applications. When I asked microsoft, the response was to…

Meanwhile, this week launch three Apple products that come with a free toolchain and IDE tailored perfectly to the new architecture that supports old and new UI APIs. On the Windows side, Visual Studio is still a 32bit application, and as you have pointed out, on ARM, it supports basically nothing but the ancient Win32 C API.

Post by [deleted] » Wed, Nov 11, 2020, 5:53 AM UTC

jen20 wrote: post #332

jniedrauer wrote: post #246

Earlier quoted context omitted.

Each HTTP request in a Go webserver spawns a goroutine, and there is no need to think about "freeing up threads" since coroutines are not OS threads. There's also no need to leak the word `async` all over your codebase. The problem being solved here with async/await is also being caused by async/await.

The issue is that Go simply does not allow large classes of system which require direct and unfettered access to the operating system primitives to be built. I'm a huge fan of Go, but pretending the two systems are equivalent either is either disingenuous or belies misunderstanding.