Роман

Ну сборка - это то что в dll-файле, да.

Где ты прочитал о статических и динамических я не знаю, по тому загуглил сам.

Статическая сборка - это такая, сборка, которая сохранена как dll-файл.
Динамическая - которая создана при помощи System.Reflection.Emit и существует только в рантайме.

Условие цикла for написано не верно:

// for(int i = 0; i >= _inventory.Length; i++)
for(int i = 0; i < _inventory.Length; i++)

// Или если _inventory изначально может быть пуст, а значит и перебирать там нечего.
for(int i = 0; i <= _inventory.Length; i++)

Ты можешь создать сборку (грубо говоря, проект/.csproj), которая называется Service.Domain, но все классы там будут в неймспейсе (пр-ве имен) Another.Namespace
Т.е. название проекта не накладывает ограничений на названия пр-в имен, которые в нем хранятся.

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

Использовать стандартные паттерны типа MVC и MVVM. Для большинства приложений этого достаточно. Если приложение более сложное, то оно делится на компоненты в виде, опять же, стандартных библиотек и приложения/приложений.

Можно. Разрешаю

В данном случае проще всего будет просто связать оба инстанса друг с другом и использовать второй инстас как резервный. Например через банальную проверку друг друга по сети запросом каким-нибудь. Один инстанс работает, а другой проверяет, что первый инстанс работает верно. Если первый инстанс не отвечает, висит, сломался и т.п. - в работу включается второй и где-нибудь ставит флаг/файл/что угодно и как, что теперь он основной, а первый - резервный будет, когда заработает и отправляет сообщение ответственному.

Чуть более сложный вариант: использовать, например, редис для хранения состояния процесса работы и через него синхронизировать инстансы. Например: первый сервис определил для себя задачу и сообщает об этом второму, что он взял такую-то задачу или такие-то файлы. Соответственно второй сервис эти файлы не трогает. Или, оба инстанса смотрят в каталог, как только что-то обнаруживают - помещают в очередь задач. А при появлении задачи в очереди - оба сервер генерируют случайно число и так выбирают кто из них возьмет следующую задачу из очереди. Т.о. можно, этих инстансов наплодить сколько угодно.

Более правильный вариант: разделить функционально вашу задачу на несколько более простых. А именно: вместо проверки каталога, запустить на том сервере, где находится данный каталог с файлами сервис наблюдения ФС, который использует системные уведомления об изменениях файловой системы. И при наступлении нужных событий - отправляет запрос в очередь на обработку, например в тот же редис, а оттуда запрос забирает один из инстансов и обрабатывает его.

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

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

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

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

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

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

Это называется Top Level Main - https://metanit.com/sharp/tutorial/1.4.php (начиная с C# 9)
Кратко - нет смысла переделывать.
Функциональность та же самая, разница только в том, что Main() генерируется компилятором, но преимущество - можно не заморачиваться над сигнатурой (например, можно влепить async/await и не менять void на async Task)

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

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

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

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

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

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

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

NPOI и OpenXML Sdk

Убрать = 1; и = 100;
Присоединюсь к GavriKos - учить C#

Да, единственный хороший вариант хранить картинки в базе - это не хранить картинки в базе, а хранить лишь пути или идентификаторы картинок.

Главный минус картинок в ФС - это то что они будут привязаны к одному серверу. Лучше хранить картинки в другой системе (S3 или CDN) и хранить в базе их идентификаторы, чтобы потом клиент мог сам их скачать, если это необходимо. Так раздача картинок не будет привязана к основному серверу.

А клиент пусть их кэширует также у себя на диске.

В будущем я хотел бы попробовать сделать так, чтобы база была на каком-то сервере, чтобы многие могли пользоваться приложением, но не думаю, что это будет нормально работать, да и вообще не красиво( Заранее спасибо.

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

Ну и клиент на WPF не должен напрямую подключаться к MS SQL.
MS SQL должен находится где-то на сервере и спрятан за каким-то другим web-сервером (который будет написан с использованием ASP NET Core например), который будет уже отвечать за всякую логику.
Если тебе нужна локальная база данных на клиенте (для кэша например), то лучше использовать sqlite.

File.Create возвращает FileStream, т.е. он и держит файл открытым

1. async-await используй
2. Используй какую-нибудь orm-ку (EF core, Dapper, linq2db). Многие из них как правило явно запрещают параллельные запросы в рамках одной транзакции.

Но вроде чисто в теории sqlite разрешает конкурентное чтение (но не запись)