-
AspNetCoreDiagnosticScenarios
This repository has examples of broken patterns in ASP.NET Core applications
-
-
InfluxDB
Power Real-Time Data Analytics at Scale. Get real-time insights from all types of time series data with InfluxDB. Ingest, query, and analyze billions of data points in real-time with unbounded cardinality.
-
-
ASP.NET Core
ASP.NET Core is a cross-platform .NET framework for building modern cloud-based web applications on Windows, Mac, or Linux.
-
NuGet.Client
Client Tools for NuGet - including Visual Studio extensions, command line tools, and msbuild support. (Open issues on https://github.com/nuget/home/issues)
-
Roslyn
The Roslyn .NET compiler provides C# and Visual Basic languages with rich code analysis APIs.
-
SaaSHub
SaaSHub - Software Alternatives and Reviews. SaaSHub helps you find the best software and product alternatives
Important: following #prefer-asyncawait-over-directly-returning-task from https://github.com/davidfowl/AspNetCoreDiagnosticScenarios/b... is not correct.
The concerns raised are niche and edge case and task must always be forwarded as is provided there is no post-processing or resource cleanup with idisposable.
https://github.com/NuGet/NuGet2/graphs/contributors (Fowler is there with many contributions).
C# is very good as a language, have developed in it for 5+ years. The problem is the gap between what MSFT promises to management and actually delivers to developers. You really really need to fully read the fine print, think of the omissions in documentation and implement a proof-of-concept that almost implements the full solution to find out the hidden gotchas.
For example, even probably their best product VS Code only got reasonable multiple screens support last year: https://github.com/microsoft/vscode/issues/10121#issuecommen...
And then, on the other end of the spectrum, you have Teams.
> Just .GetAwaiter().GetResult() it.
That won’t work with various synchronization contexts, where doing this would cause a deadlock. There’s not much fun in trying to debug such issues.
And now that various libraries only provide async api, or worse an non-async version wrapping the async one with . GetAwaiter().GetResult(), you’ll be in for a treat updating your dependencies.
Async all the way is the answer, although various frameworks still don’t offer async hooks. Recently I ran into this for example trying to write an async validator in blazor, but that’s not possible and you have to work around it [1].
C# 5 introduced async/await almost 12 years ago. And we’re still not “async all the way”.
[1]: https://github.com/dotnet/aspnetcore/issues/40244
https://github.com/NuGet/NuGet.Client/graphs/contributors lists his profile but not as a huge contributor. His LinkedIn page suggests he moved to another project after a year:
> SDE II 2010 - 2011 1 yr Co-creator and founding developer for NuGet package manager. Designed and implemented the dependency management engine for the core NuGet as well as several other features such as the initial NuGet server implementation.
> Meant no offense
None taken.
> computervison project in c#
Yeah, for CV applications nuget.org is indeed not particularly great. Very few people are using C# for these things, people typically choose something else like Python and OpenCV.
BTW, same applies to ML libraries, most folks are using Python/Torch/CUDA stack. For that hobby project https://github.com/Const-me/Cgml/ I had to re-implement the entire tech stack in C#/C++/HLSL.
My understanding is that the .NET team is working toward this with Interceptors: https://github.com/dotnet/roslyn/blob/main/docs/features/int...