You cannot do exactly that because of one simple problem: the configuration file name is a fixed thing based on the name of the main executable module of the assembly of your application. If, say, this name is "myApplication.exe", the configuration path name is "myApplication.exe.config". For two different applications, you will have two different configuration files.
What to do instead? It depends on the purpose of the data you want to have in this file.
Alternative #1. If all the data is custom, you can use some other file with the name of your choice and load it in both applications. I would advise to use XML and the best serialization technique for this purpose would be
Data Contract. Please read about it:
https://msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx[
^].
There is one delicate moment related to finding this file by the Windows Service application. Let's assume you want to put this custom configuration type in the executable directory. For a regular interactive application, it won't be a problem. But some of the methods of calculating this path don't correctly work with the Service, because services are hosted in a different way. To learn the way which works in all cases correctly, please see my past answer:
How to find my programs directory[
^].
Alternative #2. This is my architectural approach which I used in a special case, when the Windows application used the Windows Service. But you can always do it, too, even this configuration thing is the only reason for doing so. I mean, you can always make it the case.
Here is what you can do: one of the service contracts of your Service should be some "Configuration Service". The purpose of this service would be to provide the configuration data to its clients. This way, you will need the configuration file only for the Service. The Windows application will get the configuration from the Service. You may ask: "what if I need configuration data needed to connect the Service?" I would answer: "no, you won't have such situation". This is because the service does not need to "know" any data used to connect to it; only the client need this data. Now, remember that your goal was to get identical configuration file. But in this approach, you can have non-identical configuration files: the configuration for the Windows application will only contain the data on connection to the service, and the configuration for the Service will contain data needed by both application, exactly what you want, but the common part of data will be shared through the use of the Service.
Alternative #3. This alternative is pretty exotic and it is based on some special case which might be not what you want, but I want to tell about it, just in case and also for completeness. However, the fact that you want some shared configuration data for both application suggests that this approach may work for you, too. So, let's assume that the Service application and the Windows application are closely connected. The you can join them in the same project!
Again, the idea is pretty unusual. Here is how it works: you can develop a single application which behaves like two different applications: if you start it in a usual way (through the Shell), it behaves like a Windows Application. If you start it via the Service Controller, it behaves like a Windows Service application. How to achieve that? The difference between two modes of operations is easily detected by the static property
System.Environment.UserInteractive.
You can find further detail in my past answer:
Configure Windows Service with UI[
^].
When I developed this approach, my goal was only one: to improve the debugging of the Windows Service application, which is much harder to debug than an interactive application. Indeed, I was able to debug most of the very complicated code using just the interactive "mode", while the operation for production was only in the Windows Service mode. But you can use the same technique for other purposes.
—SA
Submit an article or tip