Some file formats allow embedding a thumbnail in metadata. For example JPG allows it in the EXIF data section. Not all image formats support this, and even if they do, not all images will have it. And even if it is present, the quality might not be sufficient. I have not looked at it for years (decade+) so have no code nor libraries, but maybe googling "EXIF thumbnail c#" or similar will help.

The major values you are adding are: 1) Users who pick up your library now will get the new version and will get fewer breaking changes down the line. 2) Users already using your library will have longer to adapt to the new version, giving them more time to experiment with it and align it with their releases. As a developer I would not consider these two points "small". Just make sure you communicate clear what is in the release.

It seems you are under the impression I am preferring local time instead of UTC time. I do not. I prefer DateTimeOffset over DateTime. With DateTime you have to be carefull not making mistakes. DateTimeOffset eliminates several of these possible mistakes.

A local time in c# does not represent a unique point in time as it can't store A and B times when transitioning from daylight saving time to standard time. So once you go from local to universal... Good luck. But sure, maybe they chose an implementation that happens to always work in that specific case... But just realizing this is not clear is enough for me to stay clear of that problem.

The main advantage is that it natively protect against mistakes. It does not use the same logic internally as DateTime - it stores the offset instead of DateTimeKind. You never have to deal with DateTimeKind.Unknown (primary reason for mistakes I have seen). You never have some database layer having to be told if it is local time or utc. If some idiot use local time... Then nothing happens because it still accurately represents a unique point in time - no matter where in the world that local time was used.

Oh, that is clearer then. Funnily enough I can't really find any better reason to make a decision than avoiding developers making mistakes.

Why would it be a bad idea to store DateTimeOffset? The way to store date/time I have the most experience with is DateTime stored as UTC. But I see no reason to go back to that - what is the benefit?

Yet I have seen a developer I would clarify as highly competent do "DateTime.Now.ToUniversalTime()". I have seen code break because it did not handle DateTimeKind.Unknown and some upstream code changed. Yes, it is quite simple, yet mistakes happens.

You said it was not a great idea? I agree it is hard to clasify as "great", just an extremely simple way to minimize a problem.

Why would it be better to use DateTime than DateTimeOffset? Edit: and why would you not want to minimize the possibility of doing stupid things?

I use DateTimeOffset instead of storing in UTC. Too many things can go wrong in the conversion when using DateTime. I have seen highly experienced developers doing stupid things like DateTime.Now.ToUniversalTime()

A colleague once installed the wrong version of VS on a fresh Windows version. Once he saw the uninstall (lack of) progress indicator he did the smart thing and wiped the disk and reinstalled Windows.

It does allow multiple "entry points", so case 1: case 2: Some code break; So it can't just assume a break. Sure they can come up with rules for how it would be interpreted, but kind of glad they didn't.

Did you try this approach: Using TLS 1.3 from .NET 4.0 Application – Medo's Home Page[^]

A Google for: devexpress winui tutorial Led me to this page: Getting Started | WinUI Controls | DevExpress Documentation[^] Have you tried following that?

Funny how experience can be different. For me, unit tests speed up changing code.

Sometimes I am lazy and skip them - typically when I am not quite sure I have the main "flow" worked out. It gives a short term benefit not spending time on them, but of course that has to be paid later - so I do at least make sure to write decoupled code that I can easily add the test. If I am reasonable certain of the flow, I write the test along with the code (sometimes even before as TDD, but that is rare). It is often much faster to itterate over a code block in the test than running an application. And of course, when I do go back and write the tests I skipped I find a bug or two.... In general it works as an investment: loose an hour writing a test now, or waste a day at a later time due to lack of tests... Sometimes the hour now is worth more than the day in the future. It only becomes a problem if the cost of the day in the future isn't even considered when skipping the test.

Besides AI getting it wrong: 1) If you have concurrent writers to the queue you do not know something else does not insert a new "last" item after you checked what it is. This can of course be solved with some locking, but then we are at the next point: 2) If you do not have concurrent writers you can just capture the last item to a variable as you enqueue it.

The good thing about the new "AI" tools is that they always give a reasonable and convincing looking answer.... especially when they are wrong.

Wikipedias page on Empty set[^] shows the properties of an empty set - which defined this behavior. Personally I would have been very surprised if All() on an empty set would ever return false - as I one or another time managed to get "everything applies to all elements in the empty set" stuck in my head. :D