存储 .NET Windows 服务设置的最佳实践：服务属性设置、序列化、

发布于 2024-09-13 04:41:01 字数 235 浏览 10 评论 0原文

我正在开发一个 .NET Windows 服务，我试图存储该服务启动和运行时将使用的设置。我搜索了 SO 上的帖子，发现使用项目属性中的设置非常适合与控制台和 winforms 应用程序一起使用。然而，当涉及到使用 Windows 服务存储这些设置时，Google 和 SO 却保持沉默。

有谁知道在 .NET 服务中使用这些设置是否正确？如果不是，序列化是我的下一个最佳选择吗？有没有人对服务中的设置有实际用途，并发现最好使用特定的方法？

原文

分享到QQ

分享到微博

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

发布评论

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

剩余の解释 2024-09-20 04:41:01

我在使用 Settings.settings 时遇到问题。例如，如果您需要在运行时进行更改，则可能会出现问题：设置被最初存储在 settings.settings 文件中的设置覆盖，而不是显示的应该存储的设置根据应用程序/web.config。因此，我在属性中将所有 Web 服务代理设置设置为“静态”，并通过辅助方法从 app/web.config 手动提取它们并以编程方式设置它们。这可以避免任何问题。

我们遇到的问题的一个示例：我将我的开发计算机指向测试服务器上的 Web 服务，以测试使用该 Web 服务的代码。当代码移动到我们的测试服务器时，没有出现任何问题 - 因为测试服务器仍然指向同一测试服务器上的同一 Web 服务。然而，当我们将应用程序移动到生产服务器并重新配置 web.config 以指向生产服务器时，我们开始得到奇怪的结果。我们花了相当多的精力才查明，即使我们重新配置了应用程序以指向生产服务器的 Web 服务实现，它仍然连接到测试服务器上的 Web 服务。直到我们更改了我的开发计算机上的 settings.settings 并重新编译了应用程序后，它才起作用。除此之外，我们还注意到，如果连接到生产 Web 服务时出现 DNS 问题，它不会失败，而是会回退到我们在应用程序中创建 Web 服务代理时在 settings.settings 中指定的原始设置- 代理生成器实际上对它们进行了硬编码。因此，当出现网络中断时，它不是简单地诊断连接故障，而是简单地退回到测试服务器，我们开始遇到难以理解的数据问题。我不确定这是否是一个已知问题或者是否已修复，但这肯定是您应该注意的事情。

因此，从那时起，我总是将服务属性设置为静态，并使用辅助方法直接从 web.config 读取正确的设置并以编程方式编写它们，因为这似乎可以规避问题。

看起来我遇到的问题与你的问题无关，因为我使用的是 Web 服务，这与 Windows 服务无关，但是，在任何环境中，你需要能够在运行时更改设置，而无需重新编译可能会受到此问题的影响，因此您应该注意，如果您在开发/测试/生产环境中运行，或者实际上在任何需要在运行时重新配置应用程序（即无需重新编译）的环境中运行，使用 settings.settings 时可能会得到不可预测的结果。提防。

I've had problems with using Settings.settings. For instance, if you need to make changes at run-time, there can be problems with the settings being overridden by those that were initially stored in the settings.settings file as opposed to what's shown should be stored per the app/web.config. Consequently I make all my Web Service proxy settings "static" in the properties and pull them manually from the app/web.config via a helper method and programmatically set them. This circumvents any problems.

An example of the issue we had: I pointed my development machine to a web service on a test server to test the code that consumed the web service. When the code was moved to our test server, no problems manifested - as the test server was still pointed at the same web service on the same test server. However, when we moved the application to the production server and reconfigured the web.config to point at the production server we started getting screwy results. It took quite a bit of effort to pinpoint that even though we had reconfigured the application to point at the production server's implementation of the web service, it was still connecting to the web service on the test server. It wasn't until we changed settings.settings on my development machine and recompiled the application that it worked. Further to this, we also noted that if there were DNS problems connecting to the production web service, rather than fail, it fell back to the original settings that were specified in the settings.settings from when we created the web service proxy in our application - the proxy generator actually hard codes them. Consequently when there were network outages, instead of getting easily diagnosed connection failures, it simply fell back to the test server and we started getting incomprehensible data issues. I'm not sure if this was a known problem or if it's been fixed, but it's certainly something you should be aware of.

Consequently, since then, I've always set the service properties to static and used a helper method to read the correct settings from the web.config directly and written them programmatically as this seems to circumvent the problem.

It may seem like the problem I had has nothing to do with yours because I was using Web Services which isn't anything to do with Windows Services, however, any environment where you need to be able to change the settings at runtime without having to recompile could be affected by this issue, so you should be aware that if you run in a Dev/Test/Production environment or indeed any environment where you need your app to be reconfigured at run-time (i.e. without having to recompile) that you can get unpredictable results when using settings.settings. Beware.

回复收藏 0 原文

臻嫒无言 2024-09-20 04:41:01

我通常使用注册表来存储我的服务中所需的信息，即端口等。

string lsbkey = @"Software\mycompany\adas";

RegistryKey adaskey = Registry.LocalMachine.OpenSubKey(lsbkey, false);

try
{
    object regip = adaskey.GetValue("IP");
    object regport = adaskey.GetValue("PORT");
    localip = regip.ToString();
    localport = int.Parse(regport.ToString());
}
catch (NullReferenceException ne)
{
    localip = null;
    localport = 0;
    writelog(@"Aborting Service, IP or PORT doesn't exist in \local machine\software\mycompany\adas : "+ne.Message);
    status = 0;

}

I normally use the registry to store information I need in my service i.e port etc.

string lsbkey = @"Software\mycompany\adas";

RegistryKey adaskey = Registry.LocalMachine.OpenSubKey(lsbkey, false);

try
{
    object regip = adaskey.GetValue("IP");
    object regport = adaskey.GetValue("PORT");
    localip = regip.ToString();
    localport = int.Parse(regport.ToString());
}
catch (NullReferenceException ne)
{
    localip = null;
    localport = 0;
    writelog(@"Aborting Service, IP or PORT doesn't exist in \local machine\software\mycompany\adas : "+ne.Message);
    status = 0;

}

回复收藏 0 原文