The diff usually comes from the compiler version. I mean, nothing wrong to always target the new tfms or at least recompile the libs. But, I think we overhype this mass NuGet update each year :)

The only true valid reason to update tfms is if we utilize new APIs in BCL.

That's what I expected, almost identical.

If your lib doesn't have dependencies, the effect of targeting the new tfm is negligible (usually none).

What are the reaults if your lib doesn't target net10 explicitly, but the consumer is using net10 runtime?

In my experience, it produces very inefficient code. Also, no new approaches, no new ideas. Overall, it slows me down.

I'm sure in other areas perhaps is helpful.

To be honest, this is more obvious to me. It's easy to miss, but not "strange".

The other case was more obscure. The "dead code" contributing to allocations. Much easier to remain unnoticed.

Lovely 👍

Ok I see you started working on deterministic packaging. You're like a perpetual machine 😅

cc @kirillosenkov.com

Ideally, I'd like to create the snapshots with MS Excel. But I have to figure out reliable deterministic outputs.

Btw, what's your thought on this? I'd love ur feedback here, I'm still refining the idea and open to suggestions.
github.com/fiseni/NuSeal

Not yet.

I plan to be dual licensed from start. So, I don't think I'll publish anything until I fix all the supporting infrastructure.

The SpreadCheetah is limited in functionality (also you can't open or append existing files). ClosedXML covers more stuff.

PS. Not announced yet, but for the last 4-5 months I'm working on a new excel lib. I intend to fully implement OpenXML spec. I assume it will take me one more year.

How comitted are you to ClosedXML? It's a full featured library but not very perf oriented. I mean it's understandable, it exists for a long time, before all the perf focus in .NET

It's a compile time action, so there is no runtime overhead at all. The perf implications are based on whatever is generated.

Anyhow, I do agree with you. It hurts the "discoverability", the flow might get altered and so on.

I can't say I'm some big proponent of it. But, I observe conflicting statements in the industry.

They prefer declarative code instead of imperative. In the same time hate annotations/attributes.

You can't be more declarative than having annotations. Choose your poison.

There is a difference though.. these are not about reflection, neither aspect oriented through IL weaving..
These just produce source code, which is debuggable like anything else. It's magic, but not the burried one, hidden under carpet.

Ok now it makes sense. It seems System.Text.Json is included in the MSBuild runtime that VS uses. Example location c:\Program Files\Microsoft Visual Studio\{Version}\{Edition}\MSBuild\Current\Bin. It contains also System.Buffers, System.Memory, etc.