I'm starting to develop a Windows service. I want to use some classes from my own, that has little dependencies to some MFC classes like CString, CSocket, CArchive, CMemFile and CObject. MSDN says you need to be very careful about which pieces of MFC you use in the Windows service, but don't specifies it and don't describes the problems that can occur.
My questions are:
- what pieces of MFC can be used?
- what problems can I expect, by using MFC?
- which parts of Windows service are critical for MFC use?
- is it advisable to use ATL instead of MFC for Windows service?
I'm not sure what they mean in teh MSDN article. As long as you don't use any of the GUI functionality you'll be fine - but that's a general design issue when developing services.
That being said, ATL has functionality specifically designed for building services IIRC so you may be better off using that.
To answer your questions (to the best of my knowledge):
1) the ones you specify are no problem.
2) I guess they mean synchronization issues with UI components. As long as you don't use any CWnd-derived classes you'll be fine.
3) don't understand the question.
4) See before, plus ATL is more lightweight so you'll have to distribute less, and provides build-in functionality that'll make it less of a pain to develop the service. See e.g. CAtlServiceModuleT. You'll still be able to mostly use your own classes, as CString is shared between MFC and ATL nowadays and ATL has classes for socket programming and memory file mapping itself. It doesn't have an equivalent for CArchive, and I'm not sure what functionality you use in CObject so I can't say whether there's an equivalent in ATL. So to conclude, I'd say 'yes' to this question.
(I know this answer is a bit late and this question was already answered but MFC in services is a sore spot for me...)
CSockets, far as I recall, require a Window. It makes an invisible one in the background. I found out this the hard way when I tried include some pre-exisiting MFC code into a windows service. Maybe this was only required if you accepted socket connection - I can't recall? But it did not work! (How exactly I wasted so much time doing this w/o realizing this limitation is a long story)
CObject? If you need the runtime class id stuff use RTTI (dynamic_cast, etc...)
CString, I like CString, I know it's shared with ATL now, not sure if you pull it in w/o MFC or ATL included... You could use std::string. Also, I recall someone created a derived std::string that provided the same methods as CString. (EDIT: found the code - man!! that's a blast from the past...)
CArchive, CMemFile: do you really need these?
Anyway, as Roel said, ATL may be more helpful. I wouldn't use MFC in a server-side application (ever!) ATL? Maybe. If I needed COM, defiantly. No COM but for CAtlServiceModuleT, etc... maybe....
And another bad thing about MFC in services that I have just experienced while trying to turn a regular MFC-ATL app into a service: The use of AfxConnectionAdvise() is actually useless without a Window procedure. The threads in my service are just regular non message-pumping threads. I believe this is why I never get events fired from another COM server I have developed. That other COM server hangs on Fire_xxxEvent(), causing a big mess in the whole system.
来源：https://stackoverflow.com/questions/1163905/using-mfc-in-windows-service