Using Rebex.Mail in a Windows Service : Rebex.Mail assembly not found

Question

I am having trouble getting a Windows Service which uses Rebex Mail to install properly. The installation stops with the error that the assembly Rebex.Mail, Version=2.0.5715.0..." cannot be found.

This is my first attempt at writing a Window Service. There is a reference with Copy Local=true in my project:

C:\Program Files (x86)\Rebex Components 2015 R4.1\bin\net-4.0\Rebex.Mail.dll

Is that the proper approach, as it is with desktop applications?

Do I need to move the Rebex.Mail.dll into my project's /debug folder, so it is in the same folder as the myservice.exe?

Answer 1

.NET doesn't search Rebex Components install folders when loading referenced DLL, which means that in order to deploy your application, you should either deploy the referenced DLLs such as Rebex.Mail.dll (and its dependencies) with your application's executable into the same directory, or install the shared DLLs into Global Assembly Cache (GAC). The first option seems to be used more often nowadays.

Check out the related discussion on Stack Overflow for additional information.

Having a reference with Copy Local=true makes Visual Studio copy the references DLL into our projects's output folder (such as Debug or Release), so it should actually end up in the same folder as myservice.exe. If it's not, something is wrong somewhere...

Comments

I have confirmed that the Rebex DLLs are in my output folder with the executable.   I can install the service successfully when there are no references to Rebex DLLs; but when I add references to Rebex with Copy Local=true,  the install fails. Do these DLL names need to be included on the installutil.exe command line, when installing the service?

---

I tried reproducing this by creating a simple service that sends email to support@rebex.net using Rebex Secure Mail, but it works here - please check out my project at http://www.rebex.net/getfile/0fdbbf353b5f404b8bdf6237cb28ab23/MyService.zip and give it a try. Perhaps you are doing something differently? The installutil.exe tool actually executes the installer components from the specified assembly, so actual behavior may very quite a lot.

---

Thanks for putting that project together.  I've confirmed that the problems I was having resulted from the DLLs not being installed in the GAC using GACUTIL.EXE.

---

Actually, installing into GAC is not a requirement - placing the DLLs in the same folder as `myservice.exe` should be sufficient, and on our machines, it does indeed work. So it looks like something is configured differently at your side. Perhaps an application config? That can be used to configure quite a lot (see https://support.microsoft.com/en-us/kb/837908). AssemblyResolve event can also affect the assembly resolving process a lot.

---

In my case, the installation itself was failing until the DLLs were copied into GAC. The MSFT documentation for installutil.exe says the DLLS must be in the GAC. Anyway, its working now, and onto new questions :) Thanks again.

---

My understanding of the MSFT documentation is that only the assemblies specified using the "/AssemblyName" option must by in the GAC, but I find it a bit lacking in specifics, so who knows...
We have actually been deploying .NET services referencing third party DLLs in the same directory for more than 10 years without any issues, but are using a custom embedded installer instead of installutil.exe that makes it possible to install the service simply by running the executable from the command line with "-install" argument. I guess I should clean up the code a bit and publish it because it might be useful for our customers as well.