У меня есть несколько разных рабочих приложений С#, которые выполняют различные непрерывные задачи: отправка электронных писем из очереди, импорт новых заказов из базы данных веб-сайта в базу данных заказов, создание резервных копий и восстановление базы данных, выполнение обработки данных для OLTP -> OLAP и другие связанные задачи. Раньше я выпускал их как службы Windows, но в настоящее время я выпускаю их как обычные консольные приложения. Все они основаны на общей структуре запуска задач, которую я создал, и я доволен этим, однако я не уверен, как лучше всего развертывать эти типы приложений. Мне нравится консольная версия, потому что она быстрая и простая, и можно быстро увидеть активность и вывод программы. Недостатком является то, что на рабочем компьютере запущено несколько экранов консоли, и он становится беспорядочным. С другой стороны, метод службы, похоже, требует много времени для развертывания, и мне приходится просматривать журналы событий, чтобы увидеть сообщения. Какие есть впечатления/комментарии по этому поводу?
Лучшая методология разработки длительно работающих процессорных приложений на С#
Ответы (8)
Мне нравится подход консольного приложения. Обычно у меня все настроено, поэтому я могу передать переключатель, например -unattended, который подавляет экран консоли.
Служба Windows была бы хорошим выбором, она работает в фоновом режиме независимо от того, закрываете ли вы текущий сеанс, также вы можете настроить ее на автоматический запуск после перезапуска Windows при выполнении обновления исправлений на сервере. Вы можете записывать важные сообщения в программу просмотра событий или в таблицу базы данных.
Для подобных вещей стандартный способ сделать это с помощью служб Windows. Вы хотите, чтобы служба работала с сетевой учетной записью, поэтому для нее не требуется вошедший в систему пользователь.
Я работал над чем-то несколько лет назад, у которого были похожие проблемы. По логике мне нужен был сервис, но иногда мне нужно было посмотреть, что происходит, и вообще я хотел историю. Итак, я разработал сервис, который выполнял свою работу, каждый раз, когда он хотел войти в систему, он звонил своим подписчикам (реализован как шаблон наблюдателя).
Служба зарегистрировала собственный регистратор данных (запись в базу данных), и во время выполнения пользователь мог запустить графический интерфейс, который подключался к службе с помощью удаленного взаимодействия, чтобы стать живым слушателем!
Я собираюсь голосовать за службы Windows. Управление этими консольными приложениями станет настоящей головной болью.
Развертывание службы Windows очень просто: после первоначальной установки вы просто отключаете их и выполняете XCOPY. Нет необходимости запускать какие-либо сложные установщики. Это только наполовину сложно в первый раз, да и то просто
installutil MyApp.exe
Настройте службы для запуска под учетной записью домена для обеспечения максимальной безопасности и упрощения взаимодействия с другими машинами.
Используйте комбинацию журналов событий (с ошибками, предупреждениями и информацией) для важных уведомлений и просто выгружайте подробные журналы в текстовый файл.
Почему бы не взять лучшее из всех миров и не использовать что-то вроде:
http://topshelf-project.com/
Это позволит вам запускать вашу программу как командную строку или службу Windows.
Я не уверен, относится ли это к вашим приложениям или нет, но когда у меня есть некоторые консольные приложения, которые не зависят от пользовательского ввода, или они относятся к типу приложений, которые просто выполняют свою работу и завершают работу, я запускаю такие программы на виртуальном server, таким образом, я не вижу всплывающего экрана во время работы, а виртуальные серверы легко создавать и перезапускать.
Мы регулярно используем службы Windows в качестве фоновых процессов. Мне не нравятся приложения командной строки, так как для их запуска необходимо войти на сервер. Службы все время работают в фоновом режиме (при условии, что они запускаются автоматически). Их также легко установить с помощью инструмента командной строки sc.exe, который есть в Windows. Мне это нравится больше, чем программа-раздуватель installutil.exe. Конечно, installutil делает больше, но мне не нужно то, что он делает. Я просто хочу зарегистрировать свой сервис.
Мы также создали инфраструктуру, в которой у нас есть универсальная служба .exe, которая загружает .DLL на основе определения интерфейса, поэтому добавить новую «службу» так же просто, как добавить новую DLL и перезапустить узел службы.
Однако мы начали отходить от услуг. Проблема с ними заключается в том, что они блокируют библиотеки DLL (по понятным причинам), поэтому обновлять их очень сложно. Нам нужно остановиться, обновить, а затем перезапустить. Не сложно, а дополнительные шаги. Вместо этого мы переходим на специальные «страницы» в наших приложениях asp.net, на которых выполняются необходимые фоновые задания. Там все еще есть служба, но все, что она делает, это вызывает страницы asp.net, поэтому она не блокирует ни одну из наших DLL. Затем мы можем заменить библиотеки DLL в каталоге bin asp.net, и вступят в силу обычные правила asp.net для перезапуска домена приложения.
