MarkusSchaber
MarkusSchaber
PostsComments
CC#
Created by MarkusSchaber on 11/20/2023 in #help
Nito.AsyncEx vs DotNext.Threading
For your info: we will go with suppressing the warnings now, as we cannot easily get rid of the dependency anyways.
17 replies
CC#
Created by MarkusSchaber on 11/20/2023 in #help
Nito.AsyncEx vs DotNext.Threading
Next case:
VSTHRD003: Avoid awaiting or returning a Task representing work that was not started within your context as that can lead to deadlocks. Start the work within this context, or use JoinableTaskFactory.RunAsync to start the task and await the returned JoinableTask instead.
As far as I can see, this only applies in single threaded environments like Windows Forms or WPF, not in a free threaded environment running on the thread pool. And we sometimes store or pass some tasks around, as a kind of "promise" for a future result of an operation.
17 replies
CC#
Created by MarkusSchaber on 11/20/2023 in #help
Nito.AsyncEx vs DotNext.Threading
Ouch. We also use StreamJsonRpc. That might mean replacing the library above may not actually solve the problem. 🥴
17 replies
CC#
Created by MarkusSchaber on 11/20/2023 in #help
Nito.AsyncEx vs DotNext.Threading
I wonder what drove the maintainers to implicitly pull in the analyzers, instead of providing them optionally (as e. g. xUnit Analyzers do).
17 replies
CC#
Created by MarkusSchaber on 11/20/2023 in #help
Nito.AsyncEx vs DotNext.Threading
I guess we could. However, some guys in the QA area are a bit picky about suppressing rules, we need to give justifications. And it's inefficient to run analyzers just to completely ignore them. 🙂
17 replies
CC#
Created by MarkusSchaber on 11/20/2023 in #help
Nito.AsyncEx vs DotNext.Threading
The most annying one is the one which requires all async xunit test methods to have the ...Async suffix in their name. While we prefer this name convention for normal code, we do not want it in test methods, as the Async is a detail of the test implementation and should not appear in reports, and the test identifier should not change just because the implementation now needs to use async. Other analyzers have an exception for those test methods. Another annoying one is the analyzer which suggests to use JoinableTaskFactory when accessing Task.Result, even if it's in an if block where Task.IsComplete is checked. And, as far as I can see, the JoinableTaskFactory has quite some overhead, which is required in a WPF or WinForms Environment with a primary thread, but doesn't make sense in a ThreadPool environment like ASP.NET Core. There was some other cases which we didn't like but they were single occurrences. What annoys us most is that the implementation package pulls in the analyzer unconditionally - our policy prefers to explicitly decide about the rule set. So we started looking for alternatives, and both mentioned above seem to be stable and maintained.
17 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
Yes. I just thought I could avoid writing that kind of low level code... Seems I can't get around this before .NET 9.
23 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
Will still take some time till .NET 9 is ready then. 😦
23 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
Right now, I'm using the following code: 
    private static void FromHex(ReadOnlySpan<char> source, Span<byte> dest)
    {
        Debug.Assert(source.Length == 2*dest.Length);
        while (source.Length > 0)
        {
            dest[0] = byte.Parse(source[..2], NumberStyles.HexNumber);
            source = source[2..];
            dest = dest[1..];
        }
    }
    private static void FromHex(ReadOnlySpan<char> source, Span<byte> dest)
    {
        Debug.Assert(source.Length == 2*dest.Length);
        while (source.Length > 0)
        {
            dest[0] = byte.Parse(source[..2], NumberStyles.HexNumber);
            source = source[2..];
            dest = dest[1..];
        }
    }
It seems to work and be allocation free (without unsafe), but byte.Parse seems to have a lot of overhead. I could also write my own hex parsing, but I thought with all that optimizations for Span and Memory etc. there should be a built-in way nowadays.
23 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
Convert.FromHexString(...) already converts a hex encoded string into a byte array. I want exactly the same semantics, just the bytes should be written into a Span<byte> I provide instead of a newly allocated byte[].
23 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
I don't want that.
23 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
Right now, I have to copy the bytes from the byte[] returned by FromHexString back into my destination span, using useless CPU and producing garbage for the GC.
23 replies
CC#
Created by MarkusSchaber on 9/16/2023 in #help
❔ How to convert a hex string to a Span<byte>?
I want to pass the destination Span<byte> as a parameter. Similar to the BitConverter.TryWriteBytes(...) or Base64.EncodeToUtf8 get a destination span.
23 replies