Not that difficult actually. But it took me some time to figure out what was wrong while running an application as a Windows Service that ran fine as a Windows Application. A little bit more context is necessary.

The application is based on a plugin mechanism that like most of the plugin mechanisms make use of Reflection to load the plugin dlls. In our solution we took every dll that's inside our current running directory to examine if there's a class that implements a certain interface. To determine the current directory we used:

string directory = Environment.CurrentDirectory;

This works fine under every Windows Application. It gives back the working folder. But the trouble began with the following message:

Could not load file or assembly 'file:///C:\WINDOWS\system32\6to4svc.dll' or one of its dependencies. The module was expected to contain an assembly manifest.

Very strange message. I was thinking there was a dependency to the 6to4svc.dll within one of our plugins, but that didn't really make sense. Because the 6to4svc.dll has something to do with translation of IPv6 to IPv4. The error was very strange because we would expect this kind of error to occur in both Windows Service and Windows Application environments. The next day I was fresh, and looked again at the message. I thought, was has C:\Windows\System32\ to do with our application? At that time I began to wonder are we loading dll's from the wrong directory? Yes we were, in Windows Services the Environment.CurrentDirectory is C:\Windows\system32\, a totally wrong directory for us. We changed our code a little bit to make it run in both Windows Services and Windows Application environments.

string directory = new FileInfo(Assembly.GetExecutingAssembly().Location).DirectoryName;

It took us a while to discover this. And while this solution isn't new at all, and a lot of people will have the same or alike solution for the same problem, I didn't find a solution while Googling on the error message, so it probably will be available soon.