Сергей Соловьев

Зачем завершать процесс генерируя ошибку(token.ThrowIfCancellationRequested())?

1. Чтобы не плодить постоянно Result классы с шаблонными Cancelled.
2. Как иначе определить успешно завершилась задача или токен был отменен?

Вот есть способ завершать задачу return-ном в методе задачи.

У тебя void, а если должен вернуть что-то? См. п. 2

try-catch ресурса затратная конструкция

Если это код который запускается 10000000... раз в мс, то да - затратная. А если это бизнес-логика, которая часто меняется, то нет - так быстрее вносить изменения - просто добавь еще один обработчик (не надо вносить кучу флагов)

Это LOCK!!!!
Никогда не используй асинхронный код внутри критической секции. Че случилось:
1. Поток 1 взял лок
2. Зашел в крит. секцию
3. await перенес тебя в другой поток (например, 2)
4. Поток 2 (новый) возвращает блокировку - НО ОН ЕЕ НЕ ДЕРЖИТ

Если не веришь - попробуй то же самое, но с помощью обычного lock { } сделать. Тебя компилятор поругает

Тут 2 варианта:
1. Core должен иметь в зависимостях нужную версию, а UI будет зависеть от Core и, соответственно, от нужной библиотеки
2. Дополняя ответ OwDafuq - в Core нужно сделать свои интерфейсы обертки, которые повторяют нужный интерфейс. В UI реализуешь этот интерфейс (по факту, просто будешь делегировать вызовы).

1. Вместо числа int.TryParse получит строку
2. Вернет false
3. В numValue будет 0
4. Условие не выполнится

Почему бы не использовать встроенный класс Uri ?

Они хранятся на стеке.
Если нужно передать куда-то, то уже зависит:
- Если передается интерфейс - то боксинг и это куча
- Если исходная структура - то просто структура копируется (без боксинга)

Если интересует IDisposable - то тут без боксинга. Компилятор понимает, что нужно просто вызвать Dispose и боксинг не происходит.

struct SomeStruct: IInterface
{ }

void DoSomethingStruct(SomeStruct s)
{ }

void DoSomethingInterface(IInterface i)
{ }

void Main()
{
   var s = new SomeStruct();
   // Без боксинга
   DoSomethingStruct(s);
   // Боксинг
   DoSomethingInterface(s);
}

int Mid = 0;

У data тип IReadOnlyDictionary - в него нельзя записывать значения.

Для этого надо создавать отдельную переменную Dictionary (не data).

async Task<object?> MethodFirst(IReadOnlyDictionary<string, object>? data)
{
    var result = new Dictionary<string, object>();
    

    foreach (var product in Enum.GetValues(typeof(ProductType)))
    {
        var price = await GetCentreProductSolutionLowestPrice(countryIsoCode3, (ProductType)product, null, context.Culture, cancellationToken).ConfigureAwait(false);

        if (string.IsNullOrEmpty(price))
        {
            return await GetContentById(context, PleaseCallUs, "Please call us", cancellationToken, data);
        }

        result.Add("some data", new object());
    }

    return result;
}

var document = new XmlDocument();
document.LoadXml("""
                     <ArrayOfClient>
                     <Client>
                         <Id>1</Id>
                         <Login>hihihaha</Login>
                         <Password>P@ssW0rd</Password>
                     </Client>
                     <Client>
                         <Id>2</Id>
                         <Login>blabla</Login>
                         <Password>P@ssW0rd</Password>
                     </Client>
                     <Client>
                         <Id>3</Id>
                         <Login>login</Login>
                         <Password>P@ssW0rd</Password>
                     </Client>
                 </ArrayOfClient>
                 """);
var login = "blabla";
var foundNode = document.SelectSingleNode($"//Client/Login[text()='{login}']");

if (foundNode is not null)
{
    foundNode = foundNode.ParentNode!;
    
    var passwordNode = foundNode.SelectSingleNode("./Password")!;
    passwordNode.InnerText = "new password";
    document.Save("result.xml");
}

Да, сейчас все работает, но правильно ли это? Или включение этой опции спасает даже при отправке условно данных на 1гб?

На ASP.NET Core есть ограничение на размер запроса в 50 Мб (или около того). Нам это не подходило - мы увеличили лимит. Но проблема лежит в другом - аллокация памяти. Большие чанки заставляют аллоцировать объекты в LOH. А там они могут лежать долго и не выгружаться.

Я думаю разбить отправку по частям, но проблема в том, что отправляемые данные - коллекция классов

Судя по примеру класса Details вроде ничего не мешает отправить сначала Added, а затем Removed. А если и это не поможет, то можно стримить каждый элемент: например, сначала отправляешь кол-во элементов, а потом по одному за раз.
Смысл в том, чтобы не сериализовать один большой объект.

А если у тебя 1Гб. то это скорее файл. Его лучше чанками отправлять и на диск сохранять. А по завершении отправки начинать читать (не полностью в память загружать, а постепенно)

verLines = new byte[,]
        {{cells[0].stateXO, cells[1].stateXO, cells[2].stateXO}, 
        {cells[0].stateXO, cells[1].stateXO, cells[2].stateXO}, 
        {cells[0].stateXO, cells[1].stateXO, cells[2].stateXO}};

добавь тип byte[,]

var regex = new Regex(@"{{(tag1|tag2)}}");
var str = "blah blah {{tag1}} sadf asfdvgasaasdf {{tag2}}{{tag1}}";
var result = regex.Matches(str)
                  .Select(m => m.Groups[1])
                  .ToList();
                  
Console.WriteLine(string.Join(',', result));

Он рассчитывает в радианах, а не градусах

Во время компиляции создается класс, наследующийся от MulticastDelegate. Там и определяются.

StackOverflow

Делегат:

namespace ConsoleApp;

public delegate int Factory();

IL код

// Type: ConsoleApp.Factory 
// Assembly: ConsoleApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null
// MVID: 158825C2-2E1C-449E-A72A-66768D48C2ED
// Location: /home/user/RiderProjects/ConsoleApp/ConsoleApp/bin/Debug/net6.0/ConsoleApp.dll
// Sequence point data and variable names from /home/user/RiderProjects/ConsoleApp/ConsoleApp/bin/Debug/net6.0/ConsoleApp.pdb

.class public sealed auto ansi
  ConsoleApp.Factory
    extends [System.Runtime]System.MulticastDelegate
{

  .method public hidebysig specialname rtspecialname instance void
    .ctor(
      object 'object',
      native int 'method'
    ) runtime managed
  {
    // Can't find a body
  } // end of method Factory::.ctor

  .method public hidebysig virtual newslot instance int32
    Invoke() runtime managed
  {
    // Can't find a body
  } // end of method Factory::Invoke

  .method public hidebysig virtual newslot instance class [System.Runtime]System.IAsyncResult
    BeginInvoke(
      class [System.Runtime]System.AsyncCallback callback,
      object 'object'
    ) runtime managed
  {
    // Can't find a body
  } // end of method Factory::BeginInvoke

  .method public hidebysig virtual newslot instance int32
    EndInvoke(
      class [System.Runtime]System.IAsyncResult result
    ) runtime managed
  {
    // Can't find a body
  } // end of method Factory::EndInvoke
} // end of class ConsoleApp.Factory

Это цели атрибутов - то для чего атрибут предназначается.
RTFM

Можно ли увидеть аналог пример кода на c# java с этим типом? Как-то наглядно продемонстрировать отличие от void. Иначе никак не пойму?

Unit это специальный тип, который больше нужен для инфраструктуры. Например, в функциональных языках чтобы делать цепочки вызовов: там нет понятия инструкции, зато можно передать Unit, который возвращается функцией, которая должна быть выполнена первой.

Если хочешь в дотнете - то иди в F#. Там есть Unit, попробуй функциональное программирование.

А почему нету Типа, который ни чего не упаковывает, а просто передает двойное машинной слово?

Это long. Передавай везде его, а внутри делай каст/приведение. А вообще, зачем делать стек еще больше? Если надо передать только байт, ты предлагаешь передавать сразу 8?

кортежи в 8 байт.

Где кортежи в 8 байт?

// почему такого нету, вроде же легко можно добавить, я куча раз сталкивался,
// когда дженерик писать прям в лом, или большие изменения внесет, или еще что,
// а передать надо byte int double

Используй ограничения на дженерики - where тебе в помощь