Najlepsze wskazówki dotyczące przechowywania ustawień usługi .NET Windows: Ustawienia usługi Service Serialization,

Question

Pracuję w usłudze Windows .NET, w której próbuję zapisać ustawienia, które będą używane, gdy usługa zostanie uruchomiona i gdy jest ona uruchomiona. bieganie. Przeszukałem posty na SO i stwierdziłem, że używanie ustawień we właściwościach projektu jest świetne do użytku z aplikacjami konsolowymi i WinForm. Jednak Google i SO milczą, gdy chodzi o przechowywanie tych ustawień za pomocą usługi Windows.

Czy ktoś wie, czy warto używać tych ustawień w usłudze .NET? Jeśli nie, to Serializacja jest moim kolejnym najlepszym wyborem? Czy ktokolwiek miał praktyczne zastosowania ustawień w usłudze i stwierdził, że najlepiej jest użyć konkretnej metody?

Answer 1

Miałem problemy z korzystaniem z Settings.settings. Na przykład, jeśli trzeba wprowadzić zmiany w czasie wykonywania, mogą wystąpić problemy z zastępowaniem ustawień przez te, które były początkowo przechowywane w pliku settings.settings, w przeciwieństwie do tego, co pokazano, aby przechowywać je w aplikacji/Internecie. .config. W związku z tym wszystkie moje ustawienia proxy usług sieciowych są "statyczne" we właściwościach i wyciągam je ręcznie z aplikacji/web.config za pomocą metody pomocniczej i programowo je ustawia. To omija wszelkie problemy.

Przykład problemu, który mieliśmy: Skierowałem swoją maszynę programistyczną do usługi internetowej na serwerze testowym, aby przetestować kod, który pochłonął usługę sieciową. Kiedy kod został przeniesiony na nasz serwer testowy, nie pojawiły się żadne problemy - jako że serwer testowy był ciągle wskazywany na tę samą usługę internetową na tym samym serwerze testowym. Jednak po przeniesieniu aplikacji na serwer produkcyjny i ponownym skonfigurowaniu pliku web.config na serwer produkcyjny zaczęliśmy uzyskiwać pomniejsze wyniki. Trzeba było sporo wysiłku, aby stwierdzić, że mimo że zmieniliśmy aplikację, aby wskazać serwer produkcyjny na wdrożenie usługi internetowej, wciąż łączyło się z usługą sieciową na serwerze testowym. Dopiero zmieniliśmy settings.settings na moim komputerze programistycznym i zrekompilowałem aplikację, która działała. Ponadto zauważyliśmy, że gdyby wystąpiły problemy z DNS związane z produkcyjną usługą sieciową, zamiast niepowodzenia, wróciły do ​​pierwotnych ustawień określonych w settings.settings od momentu utworzenia proxy usługi sieciowej w naszej aplikacji - generator proxy faktycznie je koduje. W rezultacie, gdy wystąpiły przerwy w sieci, zamiast łatwo zdiagnozować awarie połączeń, po prostu wróciły do ​​serwera testowego i zaczęły pojawiać się niezrozumiałe problemy z danymi. Nie jestem pewien, czy był to znany problem, czy został naprawiony, ale z pewnością jest to coś, o czym powinieneś wiedzieć.

W związku z tym, od zawsze ustawiałem właściwości usługi na statyczne i użyłem metody pomocniczej do odczytania poprawnych ustawień z web.config bezpośrednio i napisałem je programowo, ponieważ wydaje się to obchodzić problem.

Może się wydawać, że nie mam z tobą nic wspólnego, ponieważ korzystałem z usług sieciowych, które nie mają nic wspólnego z usługami systemu Windows, jednak w każdym środowisku, w którym musisz mieć możliwość zmiany ustawień na stronie Środowisko wykonawcze bez konieczności ponownej kompilacji może zostać naruszone przez ten problem, więc powinieneś mieć świadomość, że jeśli działasz w środowisku Dev/Test/Production lub w jakimkolwiek środowisku, w którym potrzebujesz aplikacji do rekonfiguracji w czasie wykonywania (tzn. bez konieczności rekompilacja), że możesz uzyskać nieprzewidywalne wyniki podczas używania settings.settings. Strzec się.

Answer 2

Używam rzeczy Settings.settings do przechowywania konfiguracji dla moich usług i nie miałem żadnych problemów. Zwykle ustawienia użytkownika, które zostały zmienione, będą przechowywane w zwykłej, niejasnej lokalizacji, w której musisz polować, jeśli chcesz je edytować ręcznie.

Answer 3

Nie widzę powodu, aby nie używać ustawień we właściwościach projektu, tak jak w przypadku aplikacji winForms. Robimy to i działa dobrze.

Answer 4

normalnie używać rejestru do przechowywania informacji, czego potrzebuję w moim tj portu serwisowego itp

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; 

}