如何为Windows应用程序和Windows服务使用相同的app.config文件 [英] How to use same app.config file for both Windows Application and Windows Service

问题描述

我有两个项目，一个Windows应用程序和一个Windows服务。我想将Windows应用程序的app.config文件用于我的Windows服务。

可行吗？

大多数配置都适用于连接字符串等项目。

如果不可能/错误的设计，有人可以建议我一个正确的设计或帮助有一些示例代码/伪代码吗？



提前谢谢！

I have two projects, a windows application and a windows service. I want to use the app.config file of windows application for my windows service too.
Is it feasible?
Most of the configuration are same for both the projects like connection string etc.
If it is not possible/ wrong design, can someone please suggest me a correct design or help with some sample code/pseudo code?

Thanks in advance !

推荐答案

你无法做到这一点因为一个简单的问题：配置文件名是一个固定的东西，基于应用程序程序集的主可执行模块的名称。例如，如果此名称为myApplication.exe，则配置路径名称为myApplication.exe.config。对于两个不同的应用程序，您将有两个不同的配置文件。



该怎么办？这取决于您希望在此文件中包含的数据的目的。



备选方案＃1。如果所有数据都是自定义的，您可以使用其他文件和您选择的名称，并将其加载到两个应用程序中。我建议使用XML，为此目的最好的序列化技术将是 Data Contract 。请阅读相关内容：

https：/ /msdn.microsoft.com/en-us/library/ms733127%28v=vs.110%29.aspx [ ^ ]。



有一个与Windows服务应用程序查找此文件相关的微妙时刻。假设您要将此自定义配置类型放在可执行文件目录中。对于常规的交互式应用程序，它不会是一个问题。但是，计算此路径的某些方法无法正确使用服务，因为服务以不同的方式托管。要了解在所有情况下正确运行的方式，请参阅我过去的答案：

如何找到我的程序目录 [ ^ ]。



备选方案＃2。这是我在一个特殊情况下使用的架构方法，当Windows应用程序使用Windows服务时。但是你也可以随时做到这一点，即使这种配置也是这样做的唯一原因。我的意思是，你可以随时做到这一点。



这是你可以做的：你的服务的一个服务合同应该是一些配置服务。此服务的目的是向其客户端提供配置数据。这样，您将只需要服务的配置文件。 Windows应用程序将从服务获取配置。您可能会问：如果我需要连接服务所需的配置数据怎么办？我会回答：不，你不会有这种情况。这是因为该服务不需要知道用于连接它的任何数据;只有客户需要这些数据。现在，请记住，您的目标是获得相同的配置文件。但是在这种方法中，您可以拥有不同的配置文件：Windows应用程序的配置将仅包含与服务连接的数据，并且服务的配置将包含两个应用程序所需的数据，正是您想要的，但是数据的共同部分将通过使用服务来共享。



备选方案＃3。这个替代方案很有异国情调，它是基于一些可能不是你想要的特殊情况，但我想告诉它，以防万一和完整性。但是，您希望两个应用程序都需要一些共享配置数据，这表明此方法也适用于您。因此，我们假设服务应用程序和Windows应用程序紧密相连。你可以加入他们同一个项目！



再一次，这个想法很不寻常。以下是它的工作原理：您可以开发一个行为类似于两个不同应用程序的应用程序：如果以通常的方式启动它（通过Shell），它的行为就像一个Windows应用程序。如果通过服务控制器启动它，它的行为类似于Windows服务应用程序。怎么实现呢？静态属性 System.Environment.UserInteractive 可以轻松检测到两种操作模式之间的差异。



您可以在我过去的答案中找到更多详细信息：使用UI配置Windows服务 [ ^ ]。



当我开发这种方法时，我的目标只有一个：改进调试Windows Service应用程序，它比交互式应用程序更难调试。实际上，我只能使用交互式模式来调试大多数非常复杂的代码，而生产操作仅在Windows服务模式下进行。但你可以将相同的技术用于其他目的。

-SA

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

这篇关于如何为Windows应用程序和Windows服务使用相同的app.config文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！