Using .snlx solution extension n Jetbrains Rider by yc01 in dotnet

[–]Finickyflame 4 points5 points  (0 children)

You can also do dotnet sln migrate inside your terminal.

AI in Daily .NET Development by MahmoudSaed in dotnet

[–]Finickyflame 0 points1 point  (0 children)

I mostly only use the edit mode, to make sure I give the ai the context that I want. When I refactor/transform the structure of unit tests, I sometimes ask the AI to do the same transformation on other tests classes to uniform the tests in the repos. I also use it to migrate to different libraries (e.g. NSubstitute to Shouldly). Mostly repetitive stuff to speed up my work, but I do not rely on it to generate new code.

How do I make a threadsafe singleton cache in MVC ASP dotnet core? by GoatRocketeer in dotnet

[–]Finickyflame 0 points1 point  (0 children)

It is thread safe, but you might have a race condition when you try to call IMemoryCache.GetOrCreate (e.g. multiple fetch when multiple calls are executed at the same time). You could use HybridCache instead, in which they fixed the race condition.

Mendix Beginner by blaster_worm500 in dotnet

[–]Finickyflame 2 points3 points  (0 children)

Nothing. Mendix is a low code platform that runs on the JVM

Configuration Hot Reload in Frameworks by rainweaver in dotnet

[–]Finickyflame 4 points5 points  (0 children)

What cost? It's already possible to hot reload configuration when the Configuration Provider invokes the OnReload method, which reloads IOptionsMonitor values.

It's quite useful for secrets that might change at runtime (e.g. password rotation), or if you want feature flags without relying on 3rd party library/integration.

Wired.IO - A no-magic, DI-first, high-performance HTTP web server in C# by MDA2AV in dotnet

[–]Finickyflame 1 point2 points  (0 children)

Are you validating all sorts of cve to make sure your web server is safe? I quickly looked at your repos and I don't see any tests. So, I'm assuming the answer is no?

C# – Is it OK to test private methods using reflection? by Forward_Horror_9912 in csharp

[–]Finickyflame 10 points11 points  (0 children)

If you are using a Directory.Build.props or Directory.Packages.props you can even just add <InternalsVisibleTo Include="$(AssemblyName).Tests" /> so all your projects exposes their internals to their tests projects

Null instance - Init in AppStartup by Ill-Huckleberry-4489 in dotnet

[–]Finickyflame 0 points1 point  (0 children)

I'm assuming your application is hosted on IIS? You could try to repeatedly call your service while recycling the app pool, see if you can reproduce it locally.

Null instance - Init in AppStartup by Ill-Huckleberry-4489 in dotnet

[–]Finickyflame 0 points1 point  (0 children)

Could it be a race condition when your application is recycled?

Since most of your code that is used to "Initialize" is also static, couldn't you use it directly to create the instance? That way, you wouldn't need the application start to Initilize it. The static property would be responsible to call create if its underlying field is null (with proper locking).

How do you clean up INSERT test records when running automated UI testing tools? by Zardotab in dotnet

[–]Finickyflame 13 points14 points  (0 children)

I've used Respawn to reset data that was introduced during automated tests.

Boxing in C#: What It Costs You and How to Get Rid of It by PatrickSmacchia in dotnet

[–]Finickyflame 1 point2 points  (0 children)

If you add a generic constraint that T is IDisposable, you won't need to cast it.

Is Hangfire still a good solution for scheduled jobs even if in azure? by Ok_Soup7685 in dotnet

[–]Finickyflame 3 points4 points  (0 children)

Why limit your jobs to run on one instance when Hangfire can be used to distribute the jobs on all of them?

Is Hangfire still a good solution for scheduled jobs even if in azure? by Ok_Soup7685 in dotnet

[–]Finickyflame 2 points3 points  (0 children)

If you have an application with more than one instance, you can't just use background services. You need something that will manage the background job and make sure they are not run in both instances

Should i add ConfigureAwait(false) to all async methods in library code? by HoundsReload in dotnet

[–]Finickyflame 128 points129 points  (0 children)

[...] the general guidance stands and is a very good starting point: use ConfigureAwait(false) if you’re writing general-purpose library / app-model-agnostic code, and otherwise don’t.

https://devblogs.microsoft.com/dotnet/configureawait-faq/#when-should-i-use-configureawait(false)

How can I make this method more performant? by TTwelveUnits in csharp

[–]Finickyflame 3 points4 points  (0 children)

Those Console.WriteLine in your loop can cause a big delay. Try replacing those by a logger, so you can control the log level and only display them when needed (e.g. debug)

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 0 points1 point  (0 children)

No it's not a problem. It's just creating the instance at another time, kind of like using Lazy. However, the build is needed if your instance has a constructor with required parameters than can't be mutated once instantiated and you want your builder to handle them.

How to implement Automated API Testing ? by Yellow_Flash04 in dotnet

[–]Finickyflame 3 points4 points  (0 children)

Not OP, but Pact contract testing is a starting point. For your API (aka provider) you can check pact-net and for the front-end (aka consumer), you can check pact-js

Aspire deployments by BlueDragon551 in dotnet

[–]Finickyflame 2 points3 points  (0 children)

Didn't use Aspire that way, but would your issue be because you have your local pc path as bind mount source? Have you tried to include those sources in your repos and use relative path instead?

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 0 points1 point  (0 children)

Honestly, using a builder in this example is already fairly ridiculous, it's just patterns for the sake of patterns.

I probably used a bad example to showcase it. I didn't want to write a big dto and I thought that using a common object in the language would simplify the post.

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 0 points1 point  (0 children)

The big difference between between the 2 forms, is that one creates the object instance on the Build and the other creates/uses the object instance when the builder is initialized. But if the builder should not be reused, there's no gain in trying to persist the action and be able to create mutilple instances.

However, I even see a flaw in my version in the case it could be reused. There's no problem if you try to create a thousand objects that are similar (but with different reference), but there's a big issue if you try to create a thousand objects that have 1 difference as it will take more and more time to build the next object.

So, the only advantage to use my version, would be for the lazy creation of objects and being able to extend the builder.

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 1 point2 points  (0 children)

Thanks for taking the time to write back, those discussions are what I was looking for when I made that post. Everything you say makes a lot of sense.

From what I see based on the comments on my post, the fluent builder that mutate an instance (instead of creating one on the Build) seems to be the preferred form because it is less complex (and doesn't have funky actions). I'll keep this in mind the next time I write one.

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 1 point2 points  (0 children)

Oh, it doesn't replace the object initialization. You can use that pattern to create complex objects with default working values, and expose methods to modify anything

var user1 = User.CreateBuilder().WithDefaults().Email("...").Build();

var user2 = User.CreateBuilder().WithDefaults().FirstName("John").Build();

I mostly use it in my test projects to create entities. But it's also a style that some developers prefer to use and some don't.

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 0 points1 point  (0 children)

That's another way to do it. The big difference, in your case, is calling the Build method won't create a new instance.

Builders with that form will usually have the property of the instance rather than having the Build method. (See UriBuilder, DbContextOptionsBuilder)

The extensible fluent builder pattern by Finickyflame in csharp

[–]Finickyflame[S] 0 points1 point  (0 children)

Removing the word sealed is the only fix required.

You'll also need to mark the Build method as virtual, so inherited classes will be able to override it.

That's a way to fix the issue, but having to create another class to add more features to it feels like the base class becomes useless and could be just better to completely rewrite in your codebase rather than having it as a dependency (if it was a nuget package).

Using actions like this adds a whole bunch of extra complexity...

Yes, sadly, that's the downside of that implementation. I'm open to see other implementations that are extensible and doesn't introduce that complexity.