Есть форма, достаточно простая. Все что на ней есть — таймер и метод который он вызывает.
Нужно все это сделать в виде Windows Service ( в частности под платформу 2003 ). Используется .NET 3.5 .

Здравствуйте, Аноним, Вы писали:

Для начала, перепишите всё в виде консольного приложения, которому не требуется ввод пользователя.

Здравствуйте, adontz, Вы писали:

A>Для начала, перепишите всё в виде консольного приложения, которому не требуется ввод пользователя.

ИМХО, слово "консольного" тут лишнее.

Здравствуйте, Аноним, Вы писали:

А>Нужно все это сделать в виде Windows Service ( в частности под платформу 2003 ). Используется .NET 3.5 .

Important. Services cannot directly interact with a user as of Windows Vista.

Источник: Interactive Services

Здравствуйте, adontz, Вы писали:

A>Здравствуйте, Аноним, Вы писали:

A>Для начала, перепишите всё в виде консольного приложения, которому не требуется ввод пользователя.


Ну оно сейчас не требует ввод пользователя. Я ж написал — форма+таймер+обработчик таймера.
Никаких полей ввода и прочего на ней нет

Здравствуйте, Аноним, Вы писали:

А>Ну оно сейчас не требует ввод пользователя. Я ж написал — форма+таймер+обработчик таймера.
А>Никаких полей ввода и прочего на ней нет

Я так же сказал консольное. Без зависимости от System.Windows.Forms

Здравствуйте, Аноним, Вы писали:

А>Ну оно сейчас не требует ввод пользователя. Я ж написал — форма+таймер+обработчик таймера.
А>Никаких полей ввода и прочего на ней нет

Лучше бы Вы написали, что именно вызывает затруднения, а так Ваш пост как-то не похож на вопрос, и что Вы ожидаете от обсуждения, остаётся совершенно не понятно

Здравствуйте, Jolly Roger, Вы писали:

JR>Здравствуйте, Аноним, Вы писали:

А>>Ну оно сейчас не требует ввод пользователя. Я ж написал — форма+таймер+обработчик таймера.
А>>Никаких полей ввода и прочего на ней нет

JR>Лучше бы Вы написали, что именно вызывает затруднения, а так Ваш пост как-то не похож на вопрос, и что Вы ожидаете от обсуждения, остаётся совершенно не понятно

Не понятно например как таймер реализовать, а также как выглядит "Hellow World" для Windows Service.
Я нашел в проектах студии WCF сервис, но помоему это не тоже самое.

Здравствуйте, Аноним, Вы писали:


А>Ну оно сейчас не требует ввод пользователя. Я ж написал — форма+таймер+обработчик таймера.
А>Никаких полей ввода и прочего на ней нет


И в чем проблема? Делаете новый проект типа Windows Service, в start запускаете свой таймер и копируете туда обработчик. Никакой формы не надо

Для простоты установки сервиса поищите класс WindowsServiceHelper, например здесь

Здравствуйте, Аноним, Вы писали:

А>Не понятно например как таймер реализовать

http://msdn.microsoft.com/en-us/magazine/cc164015.aspx

А>а также как выглядит "Hellow World" для Windows Service.

using (MyService service = newMyService())
{
    service.Run();
}

где MyService наследуется от ServiceBase.

Здравствуйте, Аноним, Вы писали:

А>Здравствуйте, Jolly Roger, Вы писали:

К уже сказанному добавлю, что оконный таймер, который Вы, похоже, использовали в WinForms, в сервисе скорее всего работать не будет, или будет срабатывать в потоке, мало для того подходящем( конкретно с сервисами NET я в этом плане не разбирался, просто есть подозрение). Можно заменить его System.Threading.Timer, либо организовать задержку отдельным потоком, в котором ожидать EventWaitHandle с таймаутом.

Здравствуйте, adontz, Вы писали:

A>Я так же сказал консольное. Без зависимости от System.Windows.Forms

Откуда такие предубеждения? Не обязан сервис быть консольным приложением.

Создай библиотеку, в ней класс с двумя методами: Start/Stop
По старту запускай свой таймер, по стопу останавливай. Эту библиотеку потом можно использовать в WinForms, Консоли, WinService и т.д. без ограничения

Затем поищи в Google "How Do" как создать сервис (в студии есть шаблон проекта), можно создать также инсталятор (Тоже все в студии есть)

Здравствуйте, Lexey, Вы писали:

L>Здравствуйте, adontz, Вы писали:

A>>Я так же сказал консольное. Без зависимости от System.Windows.Forms

L>Откуда такие предубеждения? Не обязан сервис быть консольным приложением.

Подозреваю, что это не предубеждения, а опыт То, что работает в сонсольке, то в 99% без переделки работает и в сервисе, чего не сказешь о GUI, в котором сильна завязка на message loop.

Здравствуйте, Lexey, Вы писали:

L>Откуда такие предубеждения? Не обязан сервис быть консольным приложением.
Я даже не уверен что сервис может быть консольным(с точки зрения C# компилятора) приложением. Но разрабатывать/отлаживать функционал будущего сервиса, удобно именно в виде консольного приложения.

Здравствуйте, Lexey, Вы писали:

A>>Я так же сказал консольное. Без зависимости от System.Windows.Forms
L>Откуда такие предубеждения? Не обязан сервис быть консольным приложением.

Не обязан, но так удобнее разрабатывать.

Здравствуйте, Аноним, Вы писали:

А>Есть форма, достаточно простая. Все что на ней есть — таймер и метод который он вызывает.
А>Нужно все это сделать в виде Windows Service ( в частности под платформу 2003 ). Используется .NET 3.5 .

Посмотрите тут: C# КАК создать приложение Службы WINDOWS (или службу) — http://social.msdn.microsoft.com/Forums/ru-RU/fordesktopru/thread/0d44315f-a3e7-4963-a885-b83a04aba9a6/#df6612cc-3fc8-4bf0-bbe5-bca46e63752f

Здравствуйте, v.a.v, Вы писали:

VAV>Я даже не уверен что сервис может быть консольным(с точки зрения C# компилятора) приложением. Но разрабатывать/отлаживать функционал будущего сервиса, удобно именно в виде консольного приложения.

Может. Можно даже довольно легко сделать консольное приложение, которое будет работать либо как сервис, либо как обычное консольное приложение, в зависимости от того, как его запускают (под SCM или "в лоб").

Здравствуйте, Jolly Roger, Вы писали:

JR>Подозреваю, что это не предубеждения, а опыт То, что работает в сонсольке, то в 99% без переделки работает и в сервисе, чего не сказешь о GUI, в котором сильна завязка на message loop.

Сам по себе Message loop не должен создавать никаких проблем — у сервиса есть "своя" нормальная оконная станция. Не стоит только ожидать какого-либо взаимодействия от юзера.
"Нативные" сервисы в виде неконсольных приложений более легковесны, чем их консольные аналоги (нет нужны создавать консоль). Скорее всего, и с .NETовскими все ровно тоже самое. Но привычка делать сервисы консольными — сильная штука. :D

Здравствуйте, Lexey, Вы писали:

L>Сам по себе Message loop не должен создавать никаких проблем — у сервиса есть "своя" нормальная оконная станция. Не стоит только ожидать какого-либо взаимодействия от юзера.

Оконные станции тут ни при чём, они есть всегда, не бывает процессов вне оконных станций. Даже десктоп есть всегда, который хотя-бы, в отличии от станций, имеет отношение к передаче сообщений. Разница заключатется в самой структуре GUI приложений, которые имеют ярко выраженную "событийную" модель и строятся вокруг обработчиков оконных сообщений. Именно это делает их не слишком удобными для отработки логики сервисов. Повторюсь, во избежании недопонимания — их для этого использовать можно, если понимаешь, что делаешь, но часто именно неудобно. Кроме того, не всё, что нормально работает в GUI-приложении, будет также хорошо работать в сервисе. Хороший (но далеко не единственный) тому пример — оконный таймер. Без сомнения, message loop можно вставить и в поток сервиса, да только это как раз и будет неоправданным "утяжелением".

L>"Нативные" сервисы в виде неконсольных приложений более легковесны, чем их консольные аналоги (нет нужны создавать консоль). Скорее всего, и с .NETовскими все ровно тоже самое. Но привычка делать сервисы консольными — сильная штука. :D

Вы зачем-то придумываете то, чего никто не говорил Никто не предлагал делать сервис консольным приложением (на всякий случай, чтобы не путаться в терминологии: консольное приложение — это приложение, в образе которого флаг SUBSYSTEM установлен в значение CONSOLE. Всё, данное определение исчерпывающее). Было предложено отработать логику в консольном приложении, чтобы потом перенести её в сервис. Это фактически стандартный приём, и консоль используется для вывода дополнительной отладочной информации, а также заменяет вывод в eventlog.

Здравствуйте, Lexey, Вы писали:

L>Может. Можно даже довольно легко сделать консольное приложение, которое будет работать либо как сервис, либо как обычное консольное приложение, в зависимости от того, как его запускают (под SCM или "в лоб").
Верю. Сомневался потому, что не пробовал. Делал так чтобы при запуске "в лоб"(с параметром /install), происходила "самоинсталяция" сервиса. Но компилировалось приложение как оконное(естественно без цикла обработки сообщений, и прочей "инфраструктуры"), консоль была не нужна.

А по поводу:
L>Но привычка делать сервисы консольными — сильная штука. :D
уже ответили

Здравствуйте, Jolly Roger, Вы писали:

JR>Вы зачем-то придумываете то, чего никто не говорил Никто не предлагал делать сервис консольным приложением

Это не так. Ты может и не предлагал, хотя твои слова можно интерпретировать иначе.

JR>Было предложено отработать логику в консольном приложении, чтобы потом перенести её в сервис. Это фактически стандартный приём, и консоль используется для вывода дополнительной отладочной информации, а также заменяет вывод в eventlog.

Вот это, ИМХО, уже совершенно лишние телодвижения. Хочется отладочный лог — есть Debug.Write/Print. Или Log4Net можно прикрутить.