Fix for a .Net Windows Service installation error (or more properly a failure to run after installation).
The Application Log shows:
EventType clr20r3, P1 aservice.exe, P2 22.214.171.124, P3 43d8c1c7, P4 aservice, P5 126.96.36.199, P6 43d8c1c7, P7 1a, P8 19, P9 system.io.filenotfoundexception, P10 NIL
The service installs correctly but fails either at start-up or when called upon to execute one of it’s designated tasks. The failure occurs within the .NET runtime and is not trapped by any Try/Catch within the executing module. The above error (varied by the service executable name) is seen in the Application Event Log.
The problem is caused by a missing dependency – it is very probably a COM object or a third party DLL. The DLL may be installed on the target machine but that does not mean that the .NET manifest for the service points to it’s correct location.
The quickest fix is to track down the reference in the project and set the “Copy Local” value to true in the reference properties. Then re-build your project and re-deploy it and the, now local dlls, to the directory on the target machine where the executable is located. There should be no need to re-install the service.
The problem almost certainly arrises from the use of one or more shared assembly. These should be located in the Global Assembly Cache (GAC) but the service installer component in your project takes no responsibility for installing such shared assemblies on the target machine - and indeed does not even provide a check on their availability.
The work-around described above simply treats such shared assemblies as private assemblies and these are located in the same folder as the executable.
Sick Citrix not helping
Annoying Citrix Error when trying to copy a couple of files between two directories. The first directory had copies of files with names similar to:
On copying the files to the target directory I was asked to confirm that I wanted to overwrite MyProg.vshost.exe and despite my best efforts the MyProg.exe file would not copy to the target directory once there was a copy of the MyProg.vshost.exe in residence, so to speak. The problem occurs with all similarly structured file names – not just executables.
And MS Remote Desktop keeps dying when asked to open a networked drive – a 10 minute job ends up taking all day.