Fati Iseni
@fiseni.com
Software Engineer | Microsoft MVP | .NET
https://fiseni.com
https://fiseni.com
Btw, I noticed one peculiar issue. It seems the RSA is cached in RsaSecurityKey. If you re-create a new instance, it will fail during validation. Here is a simple example.
If I disable the CacheSignatureProviders, then works each time. Not sure why is cached, but finding the root cause was tedious.
If I disable the CacheSignatureProviders, then works each time. Not sure why is cached, but finding the root cause was tedious.
August 31, 2025 at 6:46 PM
Btw, I noticed one peculiar issue. It seems the RSA is cached in RsaSecurityKey. If you re-create a new instance, it will fail during validation. Here is a simple example.
If I disable the CacheSignatureProviders, then works each time. Not sure why is cached, but finding the root cause was tedious.
If I disable the CacheSignatureProviders, then works each time. Not sure why is cached, but finding the root cause was tedious.
It seems, the closure instances are always set at the top of "locals init" section, regardless where do they appear. And that's the thing I didn't know until today, after 20 years :)
August 22, 2025 at 9:10 PM
It seems, the closure instances are always set at the top of "locals init" section, regardless where do they appear. And that's the thing I didn't know until today, after 20 years :)
Here is even more simple example. In case of min = negative number, how much do you think the Run would allocate?
You'd expect no allocation, but it will allocate for the closure (the DisplayClass).
You'd expect no allocation, but it will allocate for the closure (the DisplayClass).
August 22, 2025 at 8:15 PM
Here is even more simple example. In case of min = negative number, how much do you think the Run would allocate?
You'd expect no allocation, but it will allocate for the closure (the DisplayClass).
You'd expect no allocation, but it will allocate for the closure (the DisplayClass).
Here, I reproduced it in a simple example.
Anyhow, lesson learned. Never assume an "unreachable" code won't have any effect.
Anyhow, lesson learned. Never assume an "unreachable" code won't have any effect.
August 22, 2025 at 4:26 PM
Here, I reproduced it in a simple example.
Anyhow, lesson learned. Never assume an "unreachable" code won't have any effect.
Anyhow, lesson learned. Never assume an "unreachable" code won't have any effect.
Yep, it does the instantiation at the start of the method. What the hell? Why?
This makes me re-evaluate my life :)
This makes me re-evaluate my life :)
August 22, 2025 at 3:28 PM
Yep, it does the instantiation at the start of the method. What the hell? Why?
This makes me re-evaluate my life :)
This makes me re-evaluate my life :)
It's a closure, actually. I really have no idea why it would instate it beforehand.
August 22, 2025 at 3:19 PM
It's a closure, actually. I really have no idea why it would instate it beforehand.
None of the code will run. The first if covers all cases.
Here, I fixed the issue by just creating a local function. Now I'm back to 0 allocs.
It's weird. It means some of the closures of the dead code were instantiated somewhere at the beginning of the method? That breaks all my assumptions :)
Here, I fixed the issue by just creating a local function. Now I'm back to 0 allocs.
It's weird. It means some of the closures of the dead code were instantiated somewhere at the beginning of the method? That breaks all my assumptions :)
August 22, 2025 at 12:51 PM
None of the code will run. The first if covers all cases.
Here, I fixed the issue by just creating a local function. Now I'm back to 0 allocs.
It's weird. It means some of the closures of the dead code were instantiated somewhere at the beginning of the method? That breaks all my assumptions :)
Here, I fixed the issue by just creating a local function. Now I'm back to 0 allocs.
It's weird. It means some of the closures of the dead code were instantiated somewhere at the beginning of the method? That breaks all my assumptions :)
I'm reading this spec. Yea, it's a bit fuzzy. There are some conflicting information.
learn.microsoft.com/en-us/dotnet...
learn.microsoft.com/en-us/dotnet...
June 13, 2025 at 9:56 PM
I'm reading this spec. Yea, it's a bit fuzzy. There are some conflicting information.
learn.microsoft.com/en-us/dotnet...
learn.microsoft.com/en-us/dotnet...
Who can shed some light here? What's the rationale for allowing internal methods in the interfaces?
Once you have an internal method, consumers can no longer implement that interface. If they do not include it in their impl, it's a compiler error. But they can't include it either.
#dotnet #csharp
Once you have an internal method, consumers can no longer implement that interface. If they do not include it in their impl, it's a compiler error. But they can't include it either.
#dotnet #csharp
June 13, 2025 at 4:09 PM
To try out the experience, for the whole week, I've been requesting PR reviews from Copilot on GitHub.
While it can find some stupid and easy mistakes, for more complex code just spits out nonsense.
While it can find some stupid and easy mistakes, for more complex code just spits out nonsense.
June 13, 2025 at 3:28 PM
To try out the experience, for the whole week, I've been requesting PR reviews from Copilot on GitHub.
While it can find some stupid and easy mistakes, for more complex code just spits out nonsense.
While it can find some stupid and easy mistakes, for more complex code just spits out nonsense.
Ok, I just sat down to sketch something quickly now. The idea would be to just install a NuGet dev dependency, and you'll be able to use Merge tags to indicate that deps should be merged to the current assembly.
This is just the initial thought, still working on the idea.
This is just the initial thought, still working on the idea.
April 27, 2025 at 9:36 PM
Ok, I just sat down to sketch something quickly now. The idea would be to just install a NuGet dev dependency, and you'll be able to use Merge tags to indicate that deps should be merged to the current assembly.
This is just the initial thought, still working on the idea.
This is just the initial thought, still working on the idea.
I have zero grudge or anger towards the authors. Neither I think there is "rug-pulling" or whatever. I think the .NET Foundation should be reformed and have a different role in the ecosystem.
Here are my thoughts posted as a picture :)
#dotnet
Here are my thoughts posted as a picture :)
#dotnet
April 2, 2025 at 6:06 PM
I have zero grudge or anger towards the authors. Neither I think there is "rug-pulling" or whatever. I think the .NET Foundation should be reformed and have a different role in the ecosystem.
Here are my thoughts posted as a picture :)
#dotnet
Here are my thoughts posted as a picture :)
#dotnet
Ok, I never bash people for sharing stuff, but this is really getting out of hand!
What is this for the love of god? And hundreds of people chearing this post.
#dotnet
What is this for the love of god? And hundreds of people chearing this post.
#dotnet
March 21, 2025 at 10:58 PM
Ok, I never bash people for sharing stuff, but this is really getting out of hand!
What is this for the love of god? And hundreds of people chearing this post.
#dotnet
What is this for the love of god? And hundreds of people chearing this post.
#dotnet
I've been using a bash script for a long time. Having a dotnet tool would be more convenient.
March 9, 2025 at 12:45 PM
I've been using a bash script for a long time. Having a dotnet tool would be more convenient.
Just for fun, I rewrote the implementation in C.
Finally under 1 second (down from 42 minutes originally).
Finally under 1 second (down from 42 minutes originally).
January 13, 2025 at 1:07 PM
Just for fun, I rewrote the implementation in C.
Finally under 1 second (down from 42 minutes originally).
Finally under 1 second (down from 42 minutes originally).
Sorry pal, but this is not correct and it's not a good advice.
Yes, it should be used instead of .Result, but it doesn't save you from deadlocks. All it does, is to properly unwrap the exceptions.
Yes, it should be used instead of .Result, but it doesn't save you from deadlocks. All it does, is to properly unwrap the exceptions.
December 9, 2024 at 11:23 AM
Sorry pal, but this is not correct and it's not a good advice.
Yes, it should be used instead of .Result, but it doesn't save you from deadlocks. All it does, is to properly unwrap the exceptions.
Yes, it should be used instead of .Result, but it doesn't save you from deadlocks. All it does, is to properly unwrap the exceptions.
I was just scrolling through X now, and it feels cringe, at best.
This is how my timeline looks like. One man show 🤷♂️
This is how my timeline looks like. One man show 🤷♂️
November 23, 2024 at 1:51 AM
I was just scrolling through X now, and it feels cringe, at best.
This is how my timeline looks like. One man show 🤷♂️
This is how my timeline looks like. One man show 🤷♂️
Comments for sure have value, as long as they describe the "why" or in cases where there is some subtle background story.
Here is my example.
Here is my example.
November 17, 2024 at 6:40 PM
Comments for sure have value, as long as they describe the "why" or in cases where there is some subtle background story.
Here is my example.
Here is my example.
Going through the code now, and here is a simple example. The trimming might remove the interfaces here. So, you might need [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.Interfaces)] here
But I'm in doubt too. Should we even do it for these types of libraries? I don't know.
But I'm in doubt too. Should we even do it for these types of libraries? I don't know.
November 17, 2024 at 2:44 PM
Going through the code now, and here is a simple example. The trimming might remove the interfaces here. So, you might need [DynamicallyAccessedMembers(DynamicallyAccessedMemberTypes.Interfaces)] here
But I'm in doubt too. Should we even do it for these types of libraries? I don't know.
But I'm in doubt too. Should we even do it for these types of libraries? I don't know.
I just found this. Almost 20 years ago, before a Megadeth concert.
Damn, I got old.
Damn, I got old.
November 16, 2024 at 10:51 PM
I just found this. Almost 20 years ago, before a Megadeth concert.
Damn, I got old.
Damn, I got old.
And they support all in this list. What sorcery is this?
November 16, 2024 at 9:48 PM
And they support all in this list. What sorcery is this?
If you have a concrete collection, here is an allocation-free approach for GroupBy.
It's quite verbose code, but it removed tons of allocations.
#dotnet #aspnetcore
It's quite verbose code, but it removed tons of allocations.
#dotnet #aspnetcore
November 14, 2024 at 7:26 PM
If you have a concrete collection, here is an allocation-free approach for GroupBy.
It's quite verbose code, but it removed tons of allocations.
#dotnet #aspnetcore
It's quite verbose code, but it removed tons of allocations.
#dotnet #aspnetcore
I do get it, I'm just being overdramatic here :)
But I would lie if I said I love netstandard. The issues in old platforms are still present.
But I would lie if I said I love netstandard. The issues in old platforms are still present.
November 14, 2024 at 4:49 PM
I do get it, I'm just being overdramatic here :)
But I would lie if I said I love netstandard. The issues in old platforms are still present.
But I would lie if I said I love netstandard. The issues in old platforms are still present.