basrach

Как говорится, опыт не пропьешь. Но вот только его и не пропьешь. Если вы пока только изучаете, но пока не практикуете, то можно смело идти армию, терять по сути нечего.

COM, USB, принтеры и какие-то специфичные железяки для терминалов - та часть, где код должен быть по определению железо-зависимым. Контейнеры же про диаметрально противоположное, про абстракцию от железа и окружения. Т.е. писать софт для специфичной железяки и запускать его в контейнере, это как в истории про микроскоп и гвозди.
Вы сделали правильный вывод. Нужно выносить в контейнеры только логику независящую от какого-либо железа или оборудования. А сервисы, взаимодействующие с железом, разворачивать там где и железо.

'Edm.Int32'

Очевидно что стандартный enum невозможно конвертировать в какой-то там 'Edm.Int32'. Об этом среда вам и говорит. Если вообще проблема в этой строке.
Но так как объявления классов вы не привели, вполне может быть что и SomeProperty имеет у вас этот странный тип, в который linq не может автоматом замапить значение из БД.

Вспомнил, edm = Entity Data Model.
У вас какая-то древняя версия EF? Похоже на баг ранних версия EF. Попробуйте заменить
Error = ErrorLine.None
на

Error = (ErrorLine)1 // то значение, которое имеет None

string serverName = null;
	var cancellationTokenSource = new CancellationTokenSource(TimeSpan.FromSeconds(30));
	Task.Run(() => serverName = Server.GetServerName(), cancellationTokenSource.Token);

В таком случае вызов Server.GetServerName() будет происходить в фоне и не заблокирует основной поток. Теоретически через 30 секунд задача будет отменена. Но по факту задача будет висеть в режиме ожидание ответа по сети до тех пор, пока ответ не придет, и только после того как придет ответ будет выбран свободный поток из пула, который возьмет эту задачу для продолжения выполнения и возможно прервет её, но возможно что и не прервет.

Если вам гарантированно нужно чтобы задача не выполнилась после истечения 30 секунд, то нужно переделать метод GetServerName() следующим образом:

public string GetServerName(CancellationToken cancellationToken)
{
	// здесь непосредственно вызов по сети
	
	cancellationToken.ThrowIfCancellationRequested();
}

либо:

public string GetServerName(CancellationToken cancellationToken)
{
	// здесь непосредственно вызов по сети

	if (cancellationToken.IsCancellationRequested)
	{
		return;
	}
}

ну и соответственно его вызов будет выглядеть в таком случае вот так:

Server.GetServerName(cancellationTokenSource.Token)

Обычно для этих целей используют так называемые "очереди сообщений". Данный паттерн, очередь сообщений, широко применим и универсален. Например очередь сообщений можно построить на основе таблицы БД. В составе почти любой ОС от Microsoft есть специальный компонент под названием MSMQ, что является реализацией распределенной очереди сообщений с гарантией доставки и т.д.
Но чаще всего для ситуаций вроде вашей используют RabbitMq, хотя это уже не просто очередь, а брокер сообщений. Он популярен и у него относительно низкий порог входа. Существует множество библиотек под наверное любой язык. Так что начать работать с ним не составит большого труда. Легко разворачивается. Не требует сложной настройки, если нет особых требований. Настроить нужно только кроме роутинг сообщений. Но если использовать какую-нибудь либу, то и роутинг она может настроить автоматически. Для C# например вот хорошая библиотека. Советую посмотреть в эту сторону.

Есть два варианта.

Первый заключается в том, чтобы выгружать из БД всю коллекцию тегов. В данном случае такое решение будет вполне оправданным. Поскольку обычно задачи, и вообще что-либо, содержат 3-5 тегов, максимум 7-10, очень редко больше. В таком случае вполне нормально сделать свойство Tags у сущности Task и ожидать, что там будут всегда все теги данной задачи. Т.е. всегда загружать коллекцию тегов для задачи при восстановлении задачи из БД.

Второй заключается в том, чтобы вынести логику в Service. CA и подобные архитектуры диктуют лишь то, что бизнес логика (БЛ) должна быть первична, а все остальное вторично и подстраивается под БЛ. Но они не ограничивают в средствах выражения, т.е. необязательно чтобы вся БЛ была в методах сущностей. Наоборот, внутри сущностей должна быть лишь простая логика, а все что посложнее выносится в Domain Service-ы.
Например, можно создать TaskService, в котором будет метод AddNewTagToTask(Tag tag, Task task). Так как это сервис, то здесь можно иметь зависимость на соответствующий репозиторий, и тогда можно проверить наличие тега с помощью него: if (!taskRepository.TaskHaveTag(tag)) { ... }

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

Но стоит заметить, что если выбран второй подход, то стоит убрать свойство Tags из сущности Task. Так как это будет обманом. Представьте, что вы решили не загружать все теги для задачи, а сделать проверку через сервис. Но в проекте вы работаете не один. Другой же программист увидит что есть поле Tags у задачи и попытается использовать его так, как-будто там там содержатся все теги для задачи. Поэтому чтобы не создавать двусмысленности нужно убрать свойство Tags из Task.