Телеграмм чат группы dotnet

Size: a a a

var chat = new Chat();

2020 December 06

Обновления для .NET Core 2.1, 3.1, и .NET 5.0 будут доступны через Microsoft Update

https://devblogs.microsoft.com/dotnet/net-core-updates-coming-to-microsoft-update/

#Microsoft #Update #NET

.NET Blog

.NET Core 2.1, 3.1, and .NET 5.0 updates are coming to Microsoft Update

Delivering .NET Core 2.1, 3.1, and .NET 5.0 updates on Windows via Microsoft Update.

источник

12:51пожаловаться #1

ID:0 in var chat = new Chat();

В этом посте автор попытается упорядочить всю информацию касающуюся разработки мобильных и десктопных приложений на платформе .NET

https://nicksnettravels.builttoroam.com/net5-crossplatform/

#WinUI #MAUI #XamarinForms

Nick's .NET Travels

What's the correlation between .NET 5, WinUI and MAUI (Xamarin.Forms) - Nick's .NET Travels

Over the last couple of years there have been a couple of key developments in the .NET world. However, despite a lot of rhetoric from Microsoft about building a better developer ecosystem, the reality is that the current landscape for building apps using .NET is a mess and no amount of sugar coating is going … Continue reading "What’s the correlation between .NET 5, WinUI and MAUI (Xamarin.Forms)"

источник

13:25пожаловаться #2

Oleksii Zaichenko in var chat = new Chat();

А учитывая какие статус коды убогие и их количество

Именно поэтому я и писал, что для ошибок БЛ можно отвести 1 статус код (для всех БЛ). Не под каждую ошибку БЛ по статус коду, а один под все ошибки. Я 2жды написал, т.к. мое предыдущее усточнение на эту тему, по видимому, осталось незамеченным.

источник

14:47пожаловаться #3

Oleksii Zaichenko in var chat = new Chat();

Приведу наглядный пример почему ошибкам БЛ не место в хттп кодах:

Сегодня у вас есть какое-то АПИ, оно вас устраивает и оно поверх HTTP (а тобишь опять таки тот же RPC over JSON) и вы отдаёте ошибки БЛ статус кодами

Ваше апи популярно и у него много клиентов

Наступает момент когда нужно переехать на что-то другое, gRPC там или SOAP(упаси Боже)
И вот начинается настоящая катастрофа

У вас есть контракт описывающий типы сообщений по каждой точке, и этот контракт завязан на статус коды в случае ошибок

И тут при переезде на тот же gRPC вы понимаете что ошибки БЛ больше нельзя выразить привычным способом нормально

И полюбому начинаете городить свои варианты IsSuccess внутри сообщений или его аналоги через перечисление

Поздравляем: теперь у вас 2 разных АПИ с непохожим контрактом

> У вас есть контракт описывающий типы сообщений по каждой точке, и этот контракт завязан на статус коды в случае ошибок

Не на статус коды в случае ошибок, а как я сказал, на отдельный статус код в случае ошибки. Таким образом никакого "протекания" информации о домене не происходит. Просто абстрактно "что-то не так".

> И полюбому начинаете городить свои варианты IsSuccess внутри сообщений или его аналоги через перечисление
Поздравляем: теперь у вас 2 разных АПИ с непохожим контрактом

Даже если бы я использовал только 2хх статус код, мне бы приходилось использовать какое то isSuccess или нечто аналогичное на случай ошибки. Потребитель моего апи не сможет переехать на grpc (soap, graphql, еще черт-те что) без изменений своего кода. Модификации все равно будут.

источник

14:52пожаловаться #4

Oleksii Zaichenko in var chat = new Chat();

Хотя можно было заранее избежать такого

Под "избежать" имеется ввиду переиспользовать старую модель данных? А что если новый протокол предполагает свои способы сообщений об ошибках? Игнорить их? Потому что мы были так предусмотрительны в прошлом? Как я и сказал, клиенту все равно нужно будет писать новую версию кода для интеграции.

источник

14:56пожаловаться #5

Oleksii Zaichenko in var chat = new Chat();

И это я ещё молчу про всякие там балансеры, прокси и клаудфлеры которые могут делать с вашими статус кодами и хедерами чо хотят

Touche. Клаудфлейр - известный подсирала, на счет лоад балансера - гораздо реже. Над любым балансировщиком или обратным прокси, как правило, больше контроля. Проблемы с клаудфлейр будут решаться по мере поступления оных (которые могут и не возникнуть).

источник

14:59пожаловаться #6

Oleksii Zaichenko in var chat = new Chat();

Резюмирую, т.к. спор затянулся. Я - не против того, чтобы возвращать ошибки БЛ в 2хх кодах ответа, если это все согласовано и документировано. Моя изначальная претензия адресовалась статье на которую я и отвечал, и которая говорила о rest.
В целом, при разработке сервиса с http api я бы руководствовался теми соглашениями, которые приняты у заказчика, с которым работаю, во избежание повышения уровня энтропии так сказать. Если бы писал с нуля, очевидно, что писал бы выделяя ошибки в отдельный статус код, ибо мне так привычнее и я не вижу здесь текучей абстракции, хоть убей. На этом предлагаю спор закрыть и разойтись при своих.

источник

15:07пожаловаться #7

Artem Yurchenko in var chat = new Chat();

Привет. Кто-нибудь сталкивался с тем, что программа не автостартует через реестр? Но стартует, если просто кинуть ярлык на екзешник в папку автостарта.
Винда - десятка

источник

16:11пожаловаться #8

VD in var chat = new Chat();

Artem Yurchenko

Во первых что за программа
В вторых оффтоп

источник

16:19пожаловаться #9

Ярослав in var chat = new Chat();

Есть у кого-то статья какая-то, которая поясняет когда нужно использовать Task Parallel Library, а когда нет?

источник

16:20пожаловаться #10

Artem Yurchenko in var chat = new Chat();

Во первых что за программа
В вторых оффтоп

Я написал прогу на wpf С# .net 4.8. У юзера есть возможность отметить "Добавить в автозапуск", что прописывает "автостарт" ключ в регистр.
При старте компа программа не стартует.

источник

16:21пожаловаться #11

Pavel Erokhin in var chat = new Chat();

Artem Yurchenko

Значит ключ не записан

источник

16:21пожаловаться #12

Artem Yurchenko in var chat = new Chat();

Pavel Erokhin

Значит ключ не записан

Записан

источник