Вопрос KMBox Net — Конфликты библиотеки при интеграции в .NET Framework 4.8

[hex_cat]

KMBox Net — штука в хозяйстве полезная, но когда дело доходит до интеграции либы в старые проекты на .NET Framework 4.8, начинается настоящий ад с зависимостями. Основная проблема в том, что свежие сурсы KMBox.NET обычно скомпилены под .NET 7.0, и обратной совместимости там практически нет.

Пытаюсь прикрутить управление девайсом в старый билд на C#, и ловлю целый букет ошибок. Рантайм ругается, методы не находятся, проект просто отказывается собираться.

Спойлер: Технический разбор проблем и ошибок

1. Конфликт System.Runtime (Ошибка CS1705): Библиотека KMBox требует версию рантайма 7.0.0.0, а в проекте 4.8 висит древняя 4.1.2.0. Обычный bindingRedirect в app.config здесь не спасает — рантайм его игнорирует.
2. UdpClient и асинхронность: В .NET 7 методы SendAsync и ReceiveAsync имеют другие перегрузки. Старый фреймворк хочет явного указания длины буфера, а либа пытается слать один аргумент.
3. BitConverter и startIndex: Методы типа ToUInt32 внезапно требуют аргумент startIndex, который в более новых версиях рантайма реализован иначе.
4. Отсутствие API: RandomNumberGenerator.GetInt32() и GetValueOrDefault для ImmutableDictionary в старом 4.8 просто не существуют.

Что уже пробовал костылить:

1. Руками менял вызовы RandomNumberGenerator на стандартный Random().Next().
2. Адаптировал вызовы UDP под старые сигнатуры (добавлял .Length).
3. Подтягивал System.Collections.Immutable через NuGet, чтобы оживить словари.
4. Пытался пересобрать либу под .NET Standard 2.0 и чистый 4.8 — вылетает гора ошибок из-за отсутствующих системных API в ядре.

Несмотря на все правки в коде, конфликт версий System.Runtime остается непобежденным и блокирует компиляцию. Видимо, KMBox.NET использует слишком много «сахара» из седьмой версии, который в 4.8 завезти забыли.

Кто плотно работает с железками через C#, как решали вопрос с легаси-базами? Есть ли адекватный способ заставить проект схавать эту зависимость без полного реврайта всей логики взаимодействия под старый фреймворк?

Интересно услышать мнение тех, кто реально прокидывал управление KMBox в свои старые наработки.

 

[TheXSVV]

KMBox.Net под .NET Framework 4.8 — это боль. Проблема не в KMBox, а в **System.Runtime.CompilerServices.Unsafe** и новых API.

**Почему пересобрать не получится:**

KMBox.Net использует:
- `Unsafe.As<T>` (требует .NET Core 2.0+ / .NET 5+)
- `Span<T>` и `Memory<T>` (бэкпорт через `System.Memory` работает криво)
- `System.Net.Sockets.UdpClient` с новыми overloads (несовместимы)

**Три рабочих пути (от костыля к правильному):**

**1. Слой-прокси через локальный сервер (рекомендую)**
```csharp
// Сделай отдельную консоль на .NET 7/8
// Поднимает HttpListener или Named Pipe
// Твой старый проект шлёт команды через HTTP/Pipe
[HttpPost("/move")] Move(int x, int y) => _kmBox.Move(x, y);
```

**2. Прямой Serial порт (без KMBox.Net)**
KMBox B+ / B-Pro эмулирует HID через COM-порт. Открой порт через `SerialPort` и шли команды:
```csharp
// .NET Framework 4.8 родной
_serial.Write("km.move(100,200)\r\n");
_serial.Write("km.left_click()\r\n");
```
Вся логика KMBox.Net — просто враппер над этим.

**3. Бэкпорт (только если не работает 1 и 2)**
- Установи `System.Memory` (4.5.5) и `System.Runtime.CompilerServices.Unsafe` (6.0.0)
- Смени `TargetFramework` в `.csproj` на `net48`
- Добавь `LangVersion = 10` (позволит использовать новые фичи синтаксиса)

```xml
<PropertyGroup>
<TargetFramework>net48</TargetFramework>
<LangVersion>10.0</LangVersion>
</PropertyGroup>
```

**Почему вариант 1 — лучший:**

- Не нужно ковырять KMBox.Net
- Прокси живёт отдельно, краши не валят старый проект
- Можно переиспользовать между разными легаси-проектами
- Легко добавить шифрование команд (если боишься перехвата)

**Совет:** Забудь про пересборку KMBox.Net под 4.8. Это чёрная дыра времени. Используй прокси или прямой SerialPort — работает из коробки.