Je travaille sur un service Windows .Net où j'essaie de stocker des paramètres qui seront utilisés lorsque le service est démarré et lorsqu'il est en cours d'exécution. J'ai cherché à travers des messages sur Ainsi et j'ai constaté que l'utilisation des paramètres dans les propriétés du projet est excellente pour une utilisation avec les applications de console et de WinForms. Cependant, Google, de même, silencieux quand il se rapporte à la conservation de ces paramètres avec un service Windows.
Quelqu'un peut-il savoir s'il est approprié d'utiliser ces paramètres dans un service .NET? Sinon, la sérialisation est-elle mon prochain meilleur choix? Quelqu'un a-t-il eu des utilisations pratiques pour les paramètres dans un service et a constaté qu'il est préférable d'utiliser une méthode spécifique?
4 Réponses :
J'utilise les paramètres .Settings pour stocker la configuration pour mes services et que je n'ai eu aucun problème. Il suffit que d'habitude que les paramètres utilisateur modifiés soient stockés dans son emplacement obscur habituel que vous devez rechercher si vous souhaitez les modifier à la main.
Je ne vois aucune raison de ne pas utiliser les paramètres dans les propriétés du projet comme pour une application WinForms. Nous faisons cela, et ça marche bien.
Le problème avec l'utilisation des paramètres dans les propriétés est qu'il dépend de l'utilisateur enregistré car les paramètres sont stockés dans le profil utilisateur. Si plusieurs administrateurs utilisent le service, les paramètres vont changer.
J'ai eu des problèmes d'utilisation des paramètres.Settings. Par exemple, si vous devez apporter des modifications à l'heure d'exécution, les paramètres étant remplacés par ceux qui ont été initialement stockés dans le fichier Paramètres.Settings, par opposition à ce qui est montré devrait être stocké par l'application / web.config. Par conséquent, je rends tous mes paramètres de proxy de service de service Web "statiques" dans les propriétés et tirez-les manuellement à partir de l'application / web.config via une méthode d'assistance et de les définir par programme. Cela contourne tous les problèmes.
Un exemple du problème que nous avions: J'ai pointé ma machine de développement à un service Web sur un serveur de test pour tester le code qui consommait le service Web. Lorsque le code a été déplacé sur notre serveur de test, aucun problème ne se manifeste - car le serveur de test a toujours été signalé sur le même service Web sur le même serveur de test. Toutefois, lorsque nous avons déplacé l'application sur le serveur de production et avons reconfiguré le web.config vers le point sur le serveur de production, nous avons commencé à obtenir des résultats vissés. Il a fallu beaucoup d'efforts pour identifier que même si nous avions reconfiguré l'application sur la mise en œuvre du service Web du serveur de production, elle se connectait toujours au service Web sur le serveur de test. Ce n'était pas avant que nous ayons changé de paramètres.Settings sur ma machine de développement et recompilez l'application qu'elle a fonctionné. Suite à cela, nous avons également noté que s'il y avait des problèmes DNS se connectant au service Web de production, plutôt que de l'échec, il est retourné aux paramètres d'origine spécifiés dans les paramètres.Settings à partir de laquelle nous avons créé le proxy de service Web dans notre application. - Le générateur de proxy les codes en réalité. Par conséquent, lorsqu'il existe des pannes de réseau, au lieu d'obtenir des défaillances de connexion facilement diagnostiquées, il est simplement retourné sur le serveur de test et nous avons commencé à obtenir des problèmes de données incompréhensibles. Je ne suis pas sûr que c'était un problème connu ou si cela a été corrigé, mais c'est certainement quelque chose que vous devriez être au courant.
Par conséquent, depuis lors, j'ai toujours défini les propriétés de service sur statique et utilisée une méthode d'assistance pour lire les paramètres corrects à partir du Web.config directement et les écrit de manière programmatique car cela semble contourner le problème.
Cela peut sembler être le problème que je n'avais rien à voir avec le vôtre car j'utilisais des services Web qui ne faisait rien à voir avec Windows Services, cependant, tout environnement où vous devez pouvoir modifier les paramètres au moment de l'exécution. Sans avoir à recompiler pourraient être affectés par ce problème, vous devez donc savoir que si vous rencontrez un environnement DEV / TEST / PRODUCTION ou tout environnement où vous avez besoin de votre application à reconfiguré au moment de l'exécution (c'est-à-dire sans avoir à recompiler ) Vous pouvez obtenir des résultats imprévisibles lorsque vous utilisez des paramètres.Settings. Méfiez-vous.
Merci pour la réponse très détaillée. Je voudrais voter, mais je n'ai pas encore assez de points de réputation. Merci d'avoir pris le temps de répondre à cela.
Je dois admettre que je n'ai pas rencontré ces problèmes du tout et nous utilisons beaucoup de services Windows avec les paramètres d'application lus à partir du fichier app.config - y compris les URL du service Web. Pensez-vous que ce problème est particulièrement particulier aux applications Windows Services V Win Forms, ou juste un bogue / une question générale app.config?
@barrylloyd - Je n'ai pas fait beaucoup d'enquête sur les domaines du cadre que cela affectait pour être honnête car il s'agissait d'une demande critique de mission [c'est-à-dire. Obtenez-le bien fixé et passez à autre]. Depuis l'enquête que j'ai faite, il semblait que la question ait eu lieu concernant l'interaction du proxy de service Web avec des paramètres.Settings plutôt que de se connecter correctement au web.config pour rechercher ses paramètres. Il se peut que cela n'affecte que cette zone du cadre, cela peut affecter d'autres domaines, je ne suis pas sûr.
@barrylloyd @benalabaster Je pense que le problème est de savoir comment vous accédez aux paramètres. Je pense que c'est comme ça: si vous les accédez à l'aide de my.Settings dans vb.net, il lira le paramètre de fichier .config, mais si vous utilisez ce que vous utilisez ce qui semble être le même dans C # ( paramètres.default ), vous allez lire les paramètres par défaut compilés. Pour éviter cela dans C #, vous devez créer une instance de l'objet Paramètres que je pense. Il est bien sûr également important de vous rappeler de recharger et de sauvegarder les paramètres en cas de besoin (je le fais habituellement dans l'OntTart et l'Ontop).
Désolé pour le Necro Post, mais je voulais juste souligner que pour remplacer les paramètres par défaut, vous devez le faire dans l'assemblage "hôte". Essentiellement partout où votre programme principal () est ou global.aSax, ou startup.cs. Vous devez copier les
J'utilise normalement le registre pour stocker des informations dont j'ai besoin dans mon 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;
}