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

1. Можно поместить его в один солюшен - тогда IDE сама подскажет, если нужно импортировать
2. Можно через файл directory.props https://learn.microsoft.com/ru-ru/visualstudio/msb... - это автоматически добавит элементы в csproj, если проекты находятся в одной папке.
3. Можно завернуть в Nuget-пакет, как предлагает # - это не сделает добавление автоматическим, но добавлять будет их не сложно.

Мы вызываем нестатический метод в конструкторе, то есть экземпляра класса еще нет?

Место под него уже выделено, this есть => уже можно вызвать любой не статический метод.

Но это потенциальное пространство для ошибок, ведь компилятор не может проверить, что ты корректно всё инициализировал перед вызовом. На это даже многие инструменты для статического анализа выдадут предупреждение.

У тебя делегат твой с замыканием, а GetFunctionPointer возвращает указатель на функцию.
=> Делегат хочет обратиться к замыканию (`this.x`), а его нет.
Да и тк там this, то ещё в качестве первого аргумента должна вроде идти ссылка на экземпляр объекта-делегата.

Ну и unsafe delegate* - не делегат, а указатель на функцию по сути своей (уже настоящий)

Nlog

Кмк, он немного переусложнён.
Я бы посмотрел в сторону стандартного Microsoft.Extensions.Logging или Serilog (но из кода всё равно обращаться к M.E.L.Abstractions)

SQLite

Зачем? Какую проблему ты хочешь решить применяя для логов полноценную субд, с которой к тому же не будут нормально интегрироваться другие инструменты для просмотра логов?

На линуксе уже есть встроенная служба для логов - syslog, ей и пользуйся.

Хотя опять же зависит от того, что за приложение и что за логи.

Нет никакого "лучше". Есть только то, для чего они предназначены и об этом подробно говорится в документации.

0. Каждый из этих модификаторов имеет разные смыслы в зависимости от контекста.
1. ref struct - запрещает боксить структуру и вообще как-либо иначе заносить в кучу.
2. in (в женериках) - обозначает, что параметр контрвариантный (загугли)
3. out (в женериках) - обозначает, что параметр инвариантный (тоже загугли)
4. in/ref/out как модификатор аргументов методов - указывают, что передаваться будет ссылка (например на переменную).
in - запрещает модификацию. out - обязывает инициализировать перед завершением метода. ref - никчему не обязывает.

Из очевидных, но не ограничивающих сценариев использования (п4):
1. in - для передачи больших структур, чтобы они не копировались.
2. out - для TryParse
3. ref - для Swap
4. Ещё их всех можно использовать в P/Invoke для того же самого. Всякие нативные методы достаточно часто работают со ссылками.

Не нужно путать неймспейсы из C# с модулями из других языков.
Неймспейс проще всего воспринимать просто как приставку к названию всех типов, которые внутри неймспейса будут.
А using - подсказка компилятору, чтобы он попробовал эту приставку добавить ко всем именам, которые он ещё не смог разрешить.

1. Это для работы с COM
2. Если почитаешь подробную документацию на английском на prservesig, то всё поймёшь.
COM методы возвращают hresult, который сообщает об успехе или ошибке.
Проведение по умолчанию - всё что не успех преобразовывать в исключение.

Preservesig сохраняет оригинальную сигнатуру и отдаёт hresult как есть, что может быть полезно, если ты хочешь как-то сам его проверить и обработать без выбрасывания исключений

Код не читал, но попробуй так:

У меня есть задача: есть много текстовых файлов, заполненных рандомным текстом, в котором иногда встречаются имэйлы.
после того, как какой-то поток считал имэйлы, он должен записать их на один файл, при этом всех три потока должны записывать считаннные данные на этот один файл, не на разные файлы.

1. Для каждого из файлов запусти по потоку (таске), каждый из которых пусть свой файл читает в поисках имеилов.
2. Для записи в итоговый файл - заведи ещё 1 поток (таску).
3. Коммуникацию между N читающими и 1 пишущим организуй через System.Threading.Channel

Таким образом ты избавишься от ненужных блокировок и затрат на синхронизацию доступа к какому-то списку.

UPD: в двух и больше файлах могут быть несколько одинаковых имэйлов и считывать мне надо именно первую копию имэйла из первого файла, где эта копия встретилась, если этот имэйл имеет несколько копий в разных файлах.

UPD: тогда смотрим на количество данных.
Если имеилов мало (по сравнению с количеством ОЗУ), то тогда можем прямо в памяти держать HashSet и проверять его в пишущем потоке.
Если имеилов побольше - можем сделать HashSet не по самим и имеилам, а по их хешам.
Если имеилов совсем много, то тогда можно записывать в отсортированную структуру данных на диск (двоичное дерево поиска например).

UPD2:

Для каждого из файлов запусти по потоку (таске), каждый из которых пусть свой файл читает в поисках имеилов.

На самом деле можно попробовать запустить несколько потоков, разделив каждый файл ещё на N сегментов и назначив потокам эти сегменты. Плодить новые можно до тех пор, пока у тебя IO не кончится.

Тоже не супер новая библиотека, но написано под netstandart https://github.com/UNIT6-open/TemplateEngine.Docx

Кто-то же должен потом запустить сервис.
Как мне кажется, проще будет реально через systemd или любую другую внешнюю систему это реализовать.

Почему C# не кроссплатформенный?

На этот вопрос нельзя ответить сразу по двум причинам:
1. C# - это язык, а язык не может быть кросс-платформенным, так как платформы в разрезе языка и нет.
2. .NET уже много лет как кросс-платформенный.
Начиная с уже мейнстримного .NET 8, заканчивая mono и всякой экзотикой типа nano framework

но при этом, это не так

Ничто нельзя запустить на "чём угодно"

но в неё вопрос кроссплатформенности решена абсолютно полностью

Если вопрос "абсолютно полностью" решён, то почему я не могу запускать программы, написанные на Java, на любом железе?

Сделай из своего приложения службу. Службы запускаются в фоне и без окошка.

Получается, что скорость равна?

Нет, не равна.
Как минимум из-за того что big O показывает только характеристику, с которой растёт время.

Операция записи считается без чтения - в случае Linked List это значит, что мы пытаемся вставить, уже имея ссылку на нужный узел - нам не нужно тратить время на его поиск.

Чисто в теории, вставить элемент в середину большого Linked List будет дешевле, чем в середину большого List, тк в первом случае нам нужно будет выделить лишь небольшой кусочек памяти и поправить пару ссылок.

Во втором - придётся в худшем случае выделить кусок памяти побольше, чтобы уместились все данные и перекопировать весь список.

Конкретные числа для конкретных случаев скажет только бенчмарк.

public async Task<Country?> GetCountry(string countryCode, CancellationToken cancellationToken)
{
    var countries = await SearchCountries("en-gb", cancellationToken);
    var country = countries.Value?.FirstOrDefault(x => string.Equals(x.Code, countryCode));
    return country; // всё ок - теперь типы сходятся.
}

Это вообще правильно?

Да, это правильно и это по сути единственный адекватный способ отмены долгоиграющих операций.
Когда-то давно у потоков был метод Abort, но его удалили, тк его использование очень часто приводило к неприятным багам.
Ну и пихать проверку cancellation token повсюду не обязательно.

Поток вызывает 1 функцию библиотечную неуправляемого кода, как ее прервать?

Безопасно - никак, если эта неуправляемая функция не предоставляет интерфейс для отмены.
Даже если бы и был способ (тот же Abort), то прерывание неуправляемого кода очень вероятно приведёт к утечке ресурсов (в лучшем случае не будет освобождена динамическая память)

Но это не верно с точки зрения логики,

Почему не верно? Конкретный тип всегда можно привести к базовому.
Джон не человек? Кошка не животное?
Вот наоборот уже нельзя: например нельзя People ob = new object(); - будет ошибка, тк object - слишком абстрактный тип.

PS: чтобы не мучать отвечающего - лучше делай нормальные отступы в коде.