Использование потока. Сон () в службе Windows
Я знаю решение.
Nuget устанавливает граничную версию пакетов MySql.Data. *, В то время как у вас, вероятно, установлена предыдущая версия соединителя (в моем случае пакеты были v. 6.9.6 и Connector 6.9.5). Это приводит к тому, что у вас есть несовпадение версий.
Имейте в виду, что если вы используете Install-Package MySql.Data.Entities в NuGet, вы получите еще более старую версию, например 6.8.3, поэтому вы должны добавить ссылки по и следите за тем, какой из них вы пытаетесь добавить к своему решению.
5 ответов
Я бы использовал таймер Thread.Sleep, который может вызвать блокирующий элемент, который может помешать завершению работы службы.
Если интервал такой большой и регулярный, вы можете просто запланируйте это. Но если вы говорите о длинных непостоянных интервалах, тогда да, таймер будет лучше.
Поскольку диспетчер управления службами может запросить остановку службы в любое время, ваш поток всегда должен быть готов ответить на эти запросы, поэтому вам не следует использовать Thread.Sleep (). Вместо этого создайте событие ручного сброса в основном потоке и используйте его метод WaitOne с таймаутом в рабочем потоке. WaitOne вернет false по истечении времени.
Когда вызываются методы OnStop или OnShutdown вашего класса обслуживания, установите событие, и тогда WaitOne вернет true, и вы сможете выйти из рабочего потока.
Обычно использование Thread.Sleep () во многих случаях считается плохой практикой.
Если вы хотите, чтобы служба работала в фоновом режиме, вы следует использовать таймер.
Если службу нужно запускать только через определенные промежутки времени, я бы рекомендовал вам изучить возможность использования планировщика задач Windows, чтобы позволить Windows запускать приложение, когда вам это нужно.
Не следует заранее рассчитывать такое большое количество времени и спать часами. Спите в лучшем случае минуту, затем просыпайтесь и пересчитайте время, снова спите не более минуты. Я предполагаю, что расчет очень дешевый или его можно сделать очень дешевым с кешированием. Проблема, которую я пытаюсь смягчить, заключается в том, что компьютерные часы на удивление «скачуты», в основном из-за дрейфа времени, исправленного сетевой службой времени, а также из-за экономии дневного света и не в последнюю очередь из-за того, что пользователь настраивает часы. Поэтому лучше постоянно пересчитывать время для таких длинных интервалов, даже если это означает просыпаться каждую минуту или около того. И не удивляйтесь (т.е. не утверждайте), если вы проснетесь в «прошлом», часы могут вернуться в прошлое.
Еще одна вещь, которую следует учитывать, заключается в том, что потоки являются конечными ресурсами, и каждый поток потребляет часть памяти (1 МБ?) Для своего стека. Они также могут увеличить нагрузку на планировщик.
Теперь, если ваша служба не делает ничего другого, потраченное впустую пространство тривиально, но будет разумно знать об этом, прежде чем вы начнете выделять несколько потоков. Использование ThreadPool и / или таймеров намного эффективнее.