.NET 5.0

Post by ablekh » Wed, Nov 11, 2020, 3:23 AM UTC

cutler wrote: post #327

ablekh wrote: post #294

Earlier quoted context omitted.

In the .NET context, browser-targeted deployments can have a minimal download overhead of around 2 MB, which is a far cry from 50 MB. How? Blazor. For details, see https://blog.ndepend.com/blazor-internals-you-need-to-know .

That's 2Mb front-end which is quite heavy.

Post by jolux » Wed, Nov 11, 2020, 3:33 AM UTC

aidenn0 wrote: post #231

0xcoffee wrote: post #98

Earlier quoted context omitted.

I'm going to have to disagree here. Having a settings object is much easier then appsettings.Test.json The .json is for running the application locally. A unit test should be able to cover if a setting has value 'a, b or c', which is much easier with a regular object.

Making software harder to read, write, and maintain in the name of making unit tests easier to read, write, and maintain is putting the cart in front of the horse.

Post by davidfowl » Wed, Nov 11, 2020, 3:37 AM UTC

0xcoffee wrote: post #216

nullsense wrote: post #169

Earlier quoted context omitted.

>I agree. The first thing I always do is make a custom Settings class which just loads settings via good old `Environment.GetEnvironmentVariable`. Super simple and never failed me. The .net core configuration mechanism has a hierarchy of providers it reads from, one of which is environment variables, and strongly typed configuration is supported out of the box, so you're exact use case is supported natively by it.

I am aware of this, but like many other, I find the IOptions a bad abstraction. This blog has similar thoughts: https://rimdev.io/strongly-typed-configuration-settings-in-a... or this blog: https://adamstorr.azurewebsites.net/blog/beyond-basics-aspne... Or simply google 'asp net strongly typed configuration' and notice everyone seems to be reaching similar conclusions and building their own things. Just load the sett…

Post by davidfowl » Wed, Nov 11, 2020, 3:45 AM UTC

mattmanser wrote: post #46

tester756 wrote: post #34

Earlier quoted context omitted.

>and you're in for an even bigger nightmare if you want to separate business logic and web code into two projects (which is a pretty common design). I've given up with the config DI and just assign them all to static variables. So you have static variable in web project and then add reference to web project to obtain that config? Do I get that right? I never felt like config DI was a problem once you did all the stuf…

To me it's just so pointless, here's an example: using Microsoft.Extensions.Configuration; //extra line using Microsoft.Extensions.Options; //extra line public class AdminController : Controller { IOptions settings; //extra line public AdminController(IOptions settings) //extra code { this.settings = settings; //extra line } public void RandomMethod() { var a = settings.Value.FinallyMySetting; // 5 extra lines to acc…

Post by MarkSweep » Wed, Nov 11, 2020, 4:13 AM UTC

jniedrauer wrote: post #140

lwansbrough wrote: post #31

Earlier quoted context omitted.

Authentication is in the request pipeline, so it makes sense that it's async if you're talking to some sort of storage engine. We're using the async APIs to pull user/client app information from our database. Why would we want that to be synchronous?

> Why would we want that to be synchronous? Authentication is blocked by accessing storage. You cannot proceed until the storage read operation is completed. There is no parallel work to be accomplished here. This isn't UI code. There's no event loop. Why would you want this to be asynchronous? This seems like async as a dogma, rather than as a tool to accomplish something specific.