У меня маленький сервис на C++. Весь построен на вызовах API-функций, ни MFC, ни ATL.

Теперь есть необзодимость его перепистать. Я прочитал кучу вводных статей про C#, облизал весь RSDN-форум, но так и не понял, будет мне смысл перелезать с ним на C#, или лучше остаться на VC++ 6? Или будет смысл перелезть на ManagedC++?

Поделитесь опытом, пожалуйста...

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

S>У меня маленький сервис на C++. Весь построен на вызовах API-функций, ни MFC, ни ATL.

S>Теперь есть необзодимость его перепистать. Я прочитал кучу вводных статей про C#, облизал весь RSDN-форум, но так и не понял, будет мне смысл перелезать с ним на C#, или лучше остаться на VC++ 6? Или будет смысл перелезть на ManagedC++?

S>Поделитесь опытом, пожалуйста...

C# (точнее, fw) не покрывает весь win32. Просмотри fw на этот счет. Если у тебя специфичная задача, то C# тебе нафиг не упал — весь код будет состоять сплошь из вызова того же win32. Оно тебе надо?

Ну а если задачи типовые, то можно и на C#. Для обучения.

А если ты еще и скажешь, что у тебя за задачи, то и ответ получишь прямо тут.

Здравствуйте, Andrbig,

Задача: сервис, работающий в режиме NetworkService. Задача — обслуживание клиентских модулей, отвечающих за авторизацию в сети. А-ля софт ведения компьютерных залов, только немного специфический.

Использует: Само собой, winsvc.h; winsock2.h, wingui.h (сервисные сообщения) ну и всякая мелочевка из winuser.h.

Ни классов, ни шаблонов — ничего. Одни if, нитки и вызовы функций.

Просто у меня страсть все улучшать... И я каждый раз стараюсь не доводить ее до абсурда Жутко хочется перейти на .NET, но вот будет ли в нем толк?

А что скажешь о ManagedC++?

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

S>Задача: сервис, работающий в режиме NetworkService. Задача — обслуживание клиентских модулей, отвечающих за авторизацию в сети. А-ля софт ведения компьютерных залов, только немного специфический.
Не очень понял что такое "обслуживание клиентских модулей", модули оч-чень разные бывают. Но судя по .h у сервиса есть связь с этими модулми по tcp. Итак, сокеты, коннекты в NET есть, windows service есть, сервисные сообщения не знаю что такое, есть работа с event log, можно вызвать MessageBox из сервиса. Если этих средств хватит — вперед!

S>Просто у меня страсть все улучшать... И я каждый раз стараюсь не доводить ее до абсурда Жутко хочется перейти на .NET, но вот будет ли в нем толк?
Как минимум, освоишь новые технологии. Собственно основное, чем NET приятен программисту — там удобнее работать, чем в api: все сплошь классы, без всяких хэндлов. А так принципиальных преимуществ сервиса NET перед сервисом C++ я не вижу. Кстати, не знаю как C++ сервис, но NET сервис легко можно дебажить.

S>А что скажешь о ManagedC++?
Я когда-то думал, что раз это C++, то он может все, что умеет C# и VB. Но последний абзац статьи

Автор(ы): Алифанов Андрей
Дата: 15.02.2002
В статье рассматриваются вопросы взаимодействия программ, написанных на CLR-совместимых языках с неуправляемым кодом: с функциями Win32 API и COM-серверами.

наводит на размышления...

Я написал на MC++ работу с MAPI, потом посмотрел, посмотрел и сейчас потихоньку переписываю на C#. Он мне не понравился.

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

S>У меня маленький сервис на C++. Весь построен на вызовах API-функций, ни MFC, ни ATL.

S>перелезать с ним на C#, или лучше остаться на VC++ 6?

Зависит от того, что делает сервер. Вообще-то VC++ 6 компилятор не быстрый по сегодняшним временам. Как минимум на VC 7.1 перейти точно стоит. Ну, а если нужно упростить код и повысить его надежность, то Шарп это хороший выбор.

S> Или будет смысл перелезть на ManagedC++?

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

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

S>Использует: Само собой, winsvc.h; winsock2.h, wingui.h (сервисные сообщения) ну и всякая мелочевка из winuser.h.

Т.е. обмен по сокетам? Ну, это в дотнете есть. Так что в апи лезть не прийдется.

S>Ни классов, ни шаблонов — ничего. Одни if, нитки и вызовы функций.

Это зря. Память нужно обертывать.

S>Просто у меня страсть все улучшать... И я каждый раз стараюсь не доводить ее до абсурда Жутко хочется перейти на .NET, но вот будет ли в нем толк?

Ну, если хочется изучить, то изучай. Хуже не будет.

Я советую переписать, но без всяких сокетов. Используй .Net Remouting. Здесь есть что изучать.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

А>Я советую переписать, но без всяких сокетов. Используй .Net Remouting. Здесь есть что изучать.

Вообще-то Remoting. И переходить на него я не советую — он существует лишь до появления Indigo, в котором будут Remote Object. Это тот же Remoting, но некоторые фичи Remoting-а нынешнего будут похерены.

А>данное сообщение получено с www.gotdotnet.ru
Ну да...

Indigo — это бабка надвое сказала. А во-вторых врядли в более менее обычном проекте будет использоваться что-то сверх RegisterWellKnown..., так что врядли будут большие проблемы с обратной совместимостью или с портированием, скорее всего хватит переписать парочку конфигурационных файлов. Так что особо пугаться Remoting все же не стоит.

Не знаю стоит ли переписывать уже вполне рабочий сервис на иную платформу. А вот вообще начать осваивать FW и писать под него, желательно на С# более чем верная задача. Просто не зная еще платформы сервис легче попортить капитально, нежели портировать, тем более вы сами говорите, что в нем архитектуры в смысле ООП никакой.

---

данное сообщение получено с www.gotdotnet.ru
ссылка на оригинальное сообщение

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

А>Я советую переписать, но без всяких сокетов. Используй .Net Remouting. Здесь есть что изучать.


Как ты себе это представляешь? Тогда и клиента придется переписать на .Net.

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

А>Indigo — это бабка надвое сказала. А во-вторых врядли в более менее обычном проекте будет использоваться что-то сверх RegisterWellKnown..., так что врядли будут большие проблемы с обратной совместимостью или с портированием, скорее всего хватит переписать парочку конфигурационных файлов. Так что особо пугаться Remoting все же не стоит.

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

От себя добавлю, что на конференциях, проводимых людьми из MS, говорится что не будет CAO, а в ссылке, что я привел, обламывают и SAO. Так что в одном я согласен — бабка надвое сказала. Что же будет в этом Indigo — непонятно. Лично я свой проект с Remoting переписал на Web-Service. Мне кажется, что изменения в WS будут гораздо менее серьезными.

А>Не знаю стоит ли переписывать уже вполне рабочий сервис на иную платформу. А вот вообще начать осваивать FW и писать под него, желательно на С# более чем верная задача. Просто не зная еще платформы сервис легче попортить капитально, нежели портировать, тем более вы сами говорите, что в нем архитектуры в смысле ООП никакой.
Стоит, стоит. Самый лучший способ изучить новые технологии — начать писать на них рабочий проект. Проверено на собственной шкуре.