Mar 11, 2014 at 3:54 PM
Edited Mar 11, 2014 at 3:55 PM
I think now that I might have been using this in slightly different way than you did.
So let me describe. I wrote something you might call WindowsServiceImpl. A class which does the job and inserted it into assembly "MyServiceImpl.dll". Then I created SEPARATE service library MyService.exe. This MyService.exe DOES NOT have ANY references
to non-framework assemblies apart from MyServiceImpl.dll.
MyService.exe has an MyInstaller class and MyService class (which is just a facade). MyService.OnStart just calls MySeriviceImpl.OnStart, MyService.OnStop just calls MyServiceImpl.OnStop, and so on. Then I LibZ'ed all .dlls into MyServiceImpl.dll.
So you end up with 2 assemblies:
- MyService.exe - clean from external references, an installer class and facade class which is redirecting all calls to MyServiceImpl.dll
- MyServiceImpl.dll - doing all the job, and LibZ'ed with all external assemblies
Microsoft's InstallUtil tries to scan the whole service .exe for installers. So if you had classes doing fancy stuff inside your .exe it was failing as it could not find assemblies it needed (actually, it didn't need them but it didn't know that).
And "yes" (if you ask). You need two assemblies to properly handle service. One "clean" facade for install and other one to do the job.
NOT TESTED: Other solution would be to use "TopShelf" as a host. It is not installed with InstallUtil it just can install itself. At least AFAIU.