pojedynczy plik konfiguracyjny do sporządzania roztworu

Question

Teraz Widziałem to pytanie, zanim się na to w sposób wariantów, ale zaskakująco nie w tej formie:

mam rozwiązanie z wielu usług internetowych (projektów), które trzeba ze sobą rozmawiać inny. Po opublikowaniu każda z tych usług internetowych może trafić na inny komputer z inną bazą danych. Aby powiedzieć każdej usłudze internetowej, gdzie są wszystkie inne usługi internetowe, chcę zachować pojedynczy plik konfiguracyjny podczas programowania.

Chciałbym tego oczekiwać po opublikowaniu konfiguracji, która będzie obecna w każdym opublikowanym projekcie. I chciałbym się spodziewać, że plik konfiguracyjny będzie edytowalny po opublikowaniu, więc mogę szybko migrować określoną usługę internetową, a następnie po prostu edytować wszystkie pliki konfiguracyjne innych usług internetowych.

Nie chcę tego robić w bazie danych, ponieważ plik konfiguracyjny powinien także zawierać ustawienia połączeń do bazy danych.

natknąłem następujących pomysły/myśli/pytania:

• Mam projektu dll o nazwie „wspólne”, który odwołuje się do innych projektów. Dajmy mu jeden shared.config i zbudujmy klasę w tym projekcie, której można użyć do odczytania pliku shared.config wykonując System.Configuration.ConfigurationManager.OpenExeConfiguration("shared.config"). Wystarczy się upewnić, że plik shared.config zostanie opublikowany wraz z biblioteką DLL.

Gorąco popieram to rozwiązanie, ponieważ pozwoliłoby to również na przechowywanie pliku web.config w każdym projekcie z ustawieniami specyficznymi dla projektu. I udostępnij plik shared.config, który ma ustawienia wspólne. Ale czytam, że to nie powinno być traktowane lekko i może mieć niepożądane skutki uboczne, takie jak problemy z dostępem do plików; choć zastanawiam się, czy to dotyczy mojej sprawy. Chciałbym również poprosić o pomoc tutaj, w jaki sposób faktycznie zrealizować to, ponieważ nie sądzę Visual Studio obsługuje app.config dla projektów DLL po wyjęciu z pudełka.

• Zastanawiam się również nad tworzeniem pliku shared.config w elementach rozwiązania. Następnie łącząc ten plik wewnątrz każdego projektu. W pliku Web.config każdego projektu dodaj: <appSettings configSource="shared.config" /> wskazujący połączony plik w tym projekcie.

Chociaż nie mogę znaleźć żadnego powodu, aby tego nie robić, pierwsze wdrożenie nie powiodło się. Wygląda na to (przynajmniej podczas programowania), C# nie może odnaleźć połączonego pliku shared.config. Zgaduję, że łączenie plików nie jest wykonywane natychmiastowo ani utrzymywane po utworzeniu połączonego pliku, ale plik jest kopiowany tylko do projektów KIEDY wykonuję publikację. Tym samym pozostawiając brakujący plik podczas programowania. Czy to jest poprawne?

Answer 1

Pliki konfiguracyjne są specyficzne dla aplikacji. Oznacza to, że możesz dodać plik konfiguracyjny do biblioteki klas, ale plik zostanie następnie użyty przez aplikację (usługę Windows, serwis WWW itp.), Odwołując się do biblioteki.

To samo dotyczy zewnętrznego configSource, jest to również specyficzne dla aplikacji i musi być dołączone do projektu za jego pomocą. Więc jeśli twoje rozwiązanie składa się z 2 projektów, potrzebujesz 2 plików konfiguracyjnych. Jeden dla każdego projektu.

Podczas gdy dla aplikacji opartej na systemie Windows (usługi, winformy) oczekiwanym folderem plików konfiguracyjnych jest katalog bin, w przypadku projektów internetowych będzie to katalog główny katalogu katalogu wirtualnego.

To powiedziawszy, użycie współdzielonego pliku konfiguracyjnego wygląda na łatwiejsze rozwiązanie (i nie trzeba kopiować pliku app.config z biblioteki klas dla każdego projektu).Oto kroki:

• Utwórz folder rozwiązania.
• Dodaj do tego plik konfiguracyjny.
• Dodaj plik jako odniesienie dla każdego projektu, który go potrzebuje. Kliknij prawym przyciskiem myszy projekt i Dodaj istniejący element -> Wybierz plik i Dodaj jako odnośnik
• Upewnij się, że plik jest zawsze kopiowane przez ustawienie opcji kopiowania (właściwości pliku) wraz z kopią Zawsze.

W tym momencie powinieneś mieć plik konfiguracyjny wdrożony w katalogu projektu za każdym razem, gdy kompilujesz rozwiązanie.

EDIT:

• bym nie patrzeć do kosza do plików konfiguracyjnych w ramach aplikacji internetowej, konwencja jest to, że plik powinien znajdować się w katalogu głównym, tak by uniknąć pierwszą opcję .
• Połączone pliki trafiają do kosza po zbudowaniu projektu. Spróbuj zaimportować plik, ale tym razem po prostu dodaj go (nie jako link) i zostanie wdrożony jako zawartość w katalogu głównym Twojej witryny, więc może być zawsze dostępny.

Answer 2

Jeśli Twój hosting w usługach IIS można mieć pojedynczy plik web.config na poziomie witryny głównej, ale Giorgio ma rację, pliki app.config są specyficzne dla aplikacji. możliwe jest użycie niestandardowych kroków kompilacji w celu zautomatyzowania kopiowania plików konfiguracyjnych w wielu projektach, więc osobiście bym to zrobił.

Answer 3

To faktycznie doprowadziło mnie do szału. W końcu naprawiłem to tak:

• Utworzono plik Shared.config w projekcie DLL "common", o zawartości wyglądającej jak zwykły plik web.config/app.config.
• Ustaw plik jako Treść i Kopiuj zawsze, aby z pewnością został skopiowany do wszystkich projektów odwołujących się do wspólnego projektu. (Chociaż plik konfiguracyjny rzeczywiście znajdzie się w folderze bin.
• Utworzono klasę SharedConfiguration wewnątrz wspólnego projektu Bardzo trudną częścią było użycie Open Mapped ExeConfiguration() i pobranie ścieżki do katalogu wykonywalnego (w tym bin i bez pliku:.. // przed nim)
• teraz, gdy chcę uzyskać dostęp do ustawień z udostępnianych ustawień, robię SharedConfiguration.instance.AppSettings.Settings["CubilisEntryPointUrl"].Value

(nie mogę używać SharedConfiguration.instance.AppSettings["CubilisEntryPointUrl"] bezpośrednio z powodu this issue)

.

public static class SharedConfiguration 
{ 
    public static readonly Configuration instance = GetConfiguration("Shared.config"); 
    private static Configuration GetConfiguration(string configFileName) 
    { 
     ExeConfigurationFileMap exeConfigurationFileMap = new ExeConfigurationFileMap(); 
     Uri uri = new Uri(Path.GetDirectoryName(Assembly.GetExecutingAssembly().GetName().CodeBase)); 
     exeConfigurationFileMap.ExeConfigFilename = Path.Combine(uri.LocalPath, configFileName); 
     return ConfigurationManager.OpenMappedExeConfiguration(exeConfigurationFileMap, ConfigurationUserLevel.None); 
    } 
}