跨多个项目的 .NET App.Config 问题

发布于 2024-10-13 11:22:09 字数 1198 浏览 3 评论 0原文

我有一个包含两个项目的解决方案。一个项目是一个 Windows 服务,其中包含一些用于执行各种功能的类。另一个项目是一个 Windows 窗体应用程序,用于执行服务按需完成的各种测试和任务。例如,服务将在一定的时间间隔内执行一些不同的任务,但如果您想在该时间间隔过去之前执行其中一项任务,您可以加载 Windows 窗体应用程序并立即执行其中一项任务。 Windows 窗体应用程序(此处称为测试程序)引用 Windows 服务(此处称为服务)项目。当测试器加载时,它会从服务创建其中一个类的实例。每当按下按钮来执行任务时,它都会引用创建的实例并调用该类的各种方法。该服务使用应用程序设置进行配置,因此具有 app.config。使用 [ProjectName].Properties.Settings.Default.[SettingName] 访问配置设置。当测试仪的配置设置在其自己的app.config(或发布后的exe.config)上更改时,设置刷新不会出现问题。如果关闭测试仪,修改配置,然后重新打开,将填充新设置。如果在设置上调用 Reload 方法,则配置刷新不会出现问题。该服务以相同的方式执行。配置设置可以毫无问题地更新。

问题是,如果需要对服务进行配置更改,则当从测试器调用服务方法时,配置不会采用新设置。项目构建时使用的任何设置都会被使用。我无法让测试人员识别出服务的 app.config/exe.config 已更改,并且应重新加载并使用新配置,而不是在 Visual Studio 中构建项目时使用的任何配置。也许我对这个主题的教育还不够,但在我看来,每当构建服务时,app.config 都会汇总到服务创建的 .exe 文件中。

我尝试过封装Service的Reload方法并调用它,似乎没有什么区别。

我有一个示例项目,其在非常基本的级别上执行上述操作。理想的目标是能够动态修改 exe.config 文件,并让服务和测试器毫无问题地拾取它们。如果您想从编码的角度确切了解我的意思,可以在这里找到一个示例项目:示例解决方案

任何帮助将不胜感激。谢谢您的宝贵时间。

更新

我已经设法找到解决方案,但我仍然很好奇是否有更好的方法。通过使用在两个项目之间共享的 app.config 并使用配置管理器而不是应用程序设置,一切都会按预期进行。如果可能的话,我更喜欢使用应用程序设置;但是,使用共享的 app.config 和配置管理器指向该 app.config 是可行的。

I have a solution that contains two projects. One project is a Windows Service that contains a few classes for performing various functions. The other project is a Windows Form Application that is meant for doing various testing and performing task that the service accomplishes on demand. For instance, the service will do a few various task at a certain time interval, but if you wanted to perform one of those task before the time interval has elapsed, you could load the Windows Forms Application and execute one of the task immediately. The Windows Form Application (from here referred to as the tester) references the Windows Service (from here referred to as Service) project. When the Tester loads, it creates an instance of one of the classes from the Service. Whenever buttons are pressed to perform the task, it references that instance that was created and calls the various methods of the class. The Service has uses application settings for the configuration, and thus has an app.config. The configuration settings are accessed using [ProjectName].Properties.Settings.Default.[SettingName]. When the configuration settings for the tester are changed on its own app.config (or exe.config after release), the settings are refreshed without a problem. If the tester is closed, configuration is modified, and then reopened, the new settings will be populated. If the Reload method is called on the Settings, the configuration is refreshed without a problem. The Service performs in the same way. The configuration settings are can be updated without a problem.

The problem is that if configuration changes need to be made on the service, when the service methods are called from the tester, the configuration does not take the new settings. Whatever settings the project was built with will be used. I cannot get the tester to recognize that the app.config/exe.config for the service has changed, and the new configuration should be reloaded and used instead of whatever configuration was used when the project was built in visual studio. Perhaps it I am not educated enough about this topic, but it seems to me that the app.config is rolled up into the .exe file created by the Service whenever it is built.

I have tried encapsulating the Reload method for the Service and calling it, and it doesn't seem to make a difference.

I have an example project that performs as is described above on a very basic level. The ideal goal is to be able to modify the exe.config file or files on the fly and have both the Service and the Tester pick them up without any problems. If you would like to see exactly what I mean from a coding perspective, an example project can be found here: example solution

Any help would be greatly appreciated. Thanks you for your time.

Update

I have managed to find A solution to this, but I am still curious if there is a better way. By using an app.config that is shared between both projects and using the Configuration Manager instead of App Settings, everything works as it is expected to. I prefer to use App Settings if at all possible; however it will work to use a shared app.config and the Configuration Manager pointed at that app.config.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(2

情释 2024-10-20 11:22:09

找到了解决方案。必须将 app.config 添加到解决方案中,如我的更新中所述。这样链接后,您可以将设置文件添加到项目中,并将设置/配置添加到项目中,它们将被添加到解决方案设置文件中。这将随着构建而移动并解决我遇到的问题。

Found the solution. An app.config must be added to the solution as is described above in my update. Once linked like that, you can add a settings file to the project and add settings/configuration to the project and they will be added to the solutions settings file. This will move with the build and fix the problem I was having.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文