Василий Банников

Почему новые обновление не могут перейти например на net 6?

1. Потому что .NET 6 не имеет обратной совместимости с .NET Framework.
2. Включение .NET Runtime в состав Windows усложнит развёртывание и доставку обновлений. Будет сложно раз в год выпускать большие обновления. Сейчас можно спокойно поставить .net runtime любой версии параллельно или вообще тащить нужную версию вместе с приложением. При поставке рантайма вместе с ОС, это будет гораздо сложнее.

Или я возможно проглядел галочку при упаковке?

Типа того.
https://stackoverflow.com/questions/5205738/how-do...

Вот такая команда в результате соберёт всё в один файл. На hello world работает. Если в вашем проекте не работает - надо смотреть на код.

dotnet publish -r win-x64 --self-contained -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -o ./publish-path

https://docs.microsoft.com/en-us/dotnet/core/deplo...

Сначала замечания по реализации:

1. Раз уж мы делаем свой аналог List - тогда есть смысл вынести его в библиотеку, а не с Exe.
TargetFramework стоит делать чуть более новым. Сейчас LTS - .NET 6 (но это не так уж и критично)

2. Почему List Только для char реализован? Почему не сделать его обобщённым?

3. Почему List не реализовывает стандартные интерфейсы? Тот же IEnumerable<T> хотябы.

4. PrintForward - явно какой-то лишний метод. Список не должен отвечать за вывод в консоль.

5. Публичный сеттер в Node выглядит как что-то опасное. Так можно изменить Next или Previous - лист изменится, вплоть до изменения количества элементов, но значение Count в самом листе не изменится, от чего всё поломается.

А вот тесты наоборот выглядят вполне неплохо, но надо бы покрытие посмотреть.

Тебе нужен пакет NLog.Extensions.Logging:
https://github.com/NLog/NLog.Extensions.Logging

Но вообще советую перейти на serilog.

Нужен ли на установленный .net на платформе где будет запускаться такое .net приложение?

Когда ты публикуешь приложение для Linux - оно будет с расширением исполняемого файла от линукса.
А именно - ни с каким.
Если будешь публиковать платформонезависимое приложение, то тогда будет .dll и в любом случае понадобится установленный рантайм.

Нужен ли на установленный .net на платформе где будет запускаться такое .net приложение?

Если публиковал с флагом --self-contained или --self-contained true, то не нужен.
Если публиковал без флага --self-contained или с флагом --self-contained false, то нужен.

Это всё ты мог проверить самостоятельно, просто скомпилировав хеллоу ворлд.

PS: вот что конкретно выдаётся в результате:

C:/workspace
❯ dotnet new console -o DemoLinuxPublish
Шаблон "Консольное приложение" успешно создан.

Идет обработка действий после создания...
Выполнение "dotnet restore" для C:\workspace\DemoLinuxPublish\DemoLinuxPublish.csproj...
  Определение проектов для восстановления...
  Восстановлен C:\workspace\DemoLinuxPublish\DemoLinuxPublish.csproj (за 113 ms).
Восстановление выполнено.


C:/workspace took 2s
❯ cd .\DemoLinuxPublish\

C:/workspace/DemoLinuxPublish via .NET v6.0.100  net6.0 took 12s
❯ dotnet publish -c Release -r linux-x64 --self-contained -v q --nologo -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -p:DebugType=None -p:DebugSymbols=false -p:PublishReadyToRun=true -p:PublishTrimmed=true

C:/workspace/DemoLinuxPublish via .NET v6.0.100  net6.0 took 2s
❯ ls .\bin\Release\net6.0\linux-x64\publish\

    Directory: C:\workspace\DemoLinuxPublish\bin\Release\net6.0\linux-x64\publish

Mode                 LastWriteTime         Length Name
----                 -------------         ------ ----
-a---          21.03.2022     3:25       15866695 DemoLinuxPublish

PPS: я немного упоролся с дополнительными параметрами сборки

Твой код не скомпилируется :)
Нельзя в блок finally пихать return.
https://docs.microsoft.com/en-us/dotnet/csharp/mis...

А так вообще да - finally выполняется в любом случае, хоть выпало хоть не выпало исключение.

NRT - это просто аннотации и ничего они не обязывают. Хотя разные библиотеки могут использовать информацию из этих аннотаций.

как видим, после десериализации значения полей перепутались.

А зачем специально его запутывать? Если есть конструктор, то серилизатор будет использовать информацию из него, а ты сам его решил обмануть.
Если очень нужно так назвать - ты можешь разметить параметры при помощи атрибутов.

Инициализировать значением по-умолчанию совершенно не обязательно, хотя сделать конструктор - это хорошая идея (System.Text.Json умеет с ними хорошо работать)
Например ты можешь как значение по-умолчанию использовать "= null!; " - тогда предупреждения не будет.

И я использую Newtonsoft.Json (13.0.1)

Советую переходить на STJ

типы без ? принимать null не могут.

Формально могут. NRT ничего не гарантирует.

А если серьезно, то как все же гарантировать правильную работу кода при применении похода null reference type?
Можно ли все таки гарантировать что поле не будет равно null и при этом не пользоваться конструктором?

1. Переходи на NRT постепенно, проверяя весь код вручную, либо какими-нибудь навороченными статическими анализаторами.
2. Нет, без конструктора с проверками на null ты ничего не сможешь гарантировать.
Хотя если серилизатор очень умный и через emit напрямую фигачит в приватные поля - это также не спасёт.

Так что вот тебе дополнительная причина по скорее покрыть тестами хотябы наиболее важные сценарии в твоём приложении

Нужно создать приложение под платформу .NET 5

Тогда уж уже 6. .NET 5 скоро end of life настигнет.

Крайне желательно обеспечить отказоустойчивость всего этого дела, то есть даже если вдруг будет какой-то баг, то чтобы можно было легко закодить автоматический перезапуск.

Перезапуск решается не на уровне приложения, а на уровне выше - через systemd/docker/k8s
Они умеют автоматически отслеживать, что твой сервис упал, и перезапускать обратно.
Если сервис может сломаться не падая полностью - смотри на Health checks (https://docs.microsoft.com/en-us/aspnet/core/host-...)

получать по HTTP

Ну тут очевидно - asp net бери.
Worker Service - это про некоторую работу, которая выполняется в фоне постоянно (например слушатель очереди логичнее делать на нём)
Просто консольное приложение - будет как aspnet, только хуже (если говорить про HttpListener/TcpListener), Придётся самому изобретать AppHost чтобы отслеживать состояние сервиса.

Только не надо это всё на GET-запросах делать) Семантически корректнее будет использовать POST.

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddHttpClient();
var app = builder.Build();

app.MapPost("/value", async ([FromBody] SensorReadings data, [FromServices] HttpClient httpClient) =>
{
    // Что-то делаем с полученными данными
    await httpClient.PostAsJsonAsync("https://example.com", data);
});

app.Run();

record SensorReadings(Guid SensorId, DateTimeOffset Timestamp, double Value);

Но в принципе, раз у тебя датчики - я бы посмотрел на сочетание mqtt и worker service

и кроме как слов об оптимизаций я ничего особо не заметил....

Так и есть. В основном стабилизация и расширение уже внесённых API с повышением производительности
Возможно, в следующем превью покажут больше.
Как минимум, ожидается C# 11 с новыми фичами, например "raw string literal" и required при объявлении свойств.
Ещё ожидается стабилизация generic math и abstract static в интерфейсах.

Ну и кстати вот цитата:

Major areas of focus for .NET 7 include improved support for cloud native scenarios, tools to make it easier to upgrade legacy projects, and simplifying the developer experience by making it easier to work with containers.

Вроде как ещё на Orleans больше внимания обращают - мб в него больше фичей привнесут (ну и с Azure его интегрируют)

у .NET сейчас такой этап, что надо как-то его окупать - значит будут чуть больше внимания обращать на Azure, чем на сам .NET

var hiddenAndOffline = FileAttributes.Hidden | File.Attributes.Offline;
if((dir.Attributes & hiddenAndOffline) == hiddenAndOffline)
{
  /* Файл скрыт и offline*/
}
if((dir.Attributes & hiddenAndOffline) != 0)
{
 /* Файл скрыт или offline или всё вместе */
}

зачем делать Singleton with double check locking

Синглтон имеет смысл делать только тогда, когда (все три):
1. Не факт, что за время работы приложения, понадобится экземпляр этого класса (иначе разруливаем через обычный static)
2. Создавать его очень дорого, и его экземпляр требует много ресурсов (памяти, или может каких-то неуправляемых), по тому его нужно ещё и переиспользовать везде. (иначе зачем в принципе синглтон?)
3. Нет возможности разрулить это на уровне Dependency Injection (иначе разруливаем через DI)

Double check-lock необходим, чтобы гарантировать, что экземпляр синглтона будет создан только 1.
Считается, что создавать экземпляр синглтона дороже, чем 1 лок.
А проверка перед локом нужна затем, чтобы не блокировать лишний раз.

сказали что lock это одна из самых дешевых оперций по синхронизации.

Да, это так. Если гораздо более дорогие операции.

get
            {
                  lock (Loker)
                  {
                        // only one check and everything is fine :)
                      if (_instance == null)
                      {
                          _instance = new Singleton1();
                      }
                }

                return _instance;
            }

А зачем тебе Lock, если ты не собираешься изменять переменную?
Сначала проверяешь на null, чтобы проверить, придётся ли тебе её менять.
Потом поднимаешь lock и проверяешь снова, чтобы гарантировать, что ты один обращаешься.
Для чтения lock не нужен.
Проверка на null - гораздо дешевле, чем lock, по тому перед поднятием блокировки есть смысл проверить на null