Próbuję dodać plik app.config do mojej biblioteki DLL, ale wszystkie próby zakończyły się niepowodzeniem.
Według MusicGenesis w „ Umieszczanie informacji o konfiguracji w bibliotece DLL ” nie powinno to stanowić problemu. Więc oczywiście robię coś złego ...
Poniższy kod powinien zwrócić mój ConnectionString z mojej biblioteki DLL:
return ConfigurationManager.AppSettings["ConnectionString"];
Jednak po skopiowaniu pliku app.config do aplikacji konsoli działa dobrze.
Jakieś pomysły?
c#
app-config
MegaByte
źródło
źródło
Odpowiedzi:
Utworzenie pliku konfiguracyjnego .NET dla pliku .DLL nie jest łatwe. Mechanizm konfiguracyjny .NET ma wiele wbudowanych funkcji, które ułatwiają aktualizację / aktualizację aplikacji i chronią zainstalowane aplikacje przed wzajemnym zadeptaniem plików konfiguracyjnych.
Istnieje duża różnica między sposobem użycia biblioteki DLL a sposobem użycia aplikacji. Jest mało prawdopodobne, aby na tym samym komputerze zainstalowanych było wiele kopii aplikacji dla tego samego użytkownika. Ale możesz mieć 100 różnych aplikacji lub bibliotek, które korzystają z niektórych bibliotek DLL .NET.
Chociaż rzadko zachodzi potrzeba osobnego śledzenia ustawień dla różnych kopii aplikacji w ramach jednego profilu użytkownika, tak jest bardzo ważne mało prawdopodobne, aby wszystkie różne zastosowania biblioteki DLL współdzieliły ze sobą konfigurację. Z tego powodu, gdy pobierasz obiekt konfiguracji przy użyciu metody „normalnej”, zwracany obiekt jest powiązany z konfiguracją domeny aplikacji, w której wykonujesz, a nie z konkretnym zestawem.
Domena aplikacji jest powiązana z zestawem głównym, który załadował zestaw, w którym znajduje się Twój kod. W większości przypadków będzie to zestaw głównego pliku .EXE, który załadował plik .DLL. Możliwe jest rozpinanie innych domen aplikacji w aplikacji, ale musisz jawnie podać informacje o tym, czym jest zestaw główny tej domeny aplikacji.
Z tego powodu procedura tworzenia pliku konfiguracyjnego specyficznego dla biblioteki nie jest tak wygodna. Jest to ten sam proces, którego użyłbyś do utworzenia dowolnego przenośnego pliku konfiguracyjnego niepowiązanego z żadnym konkretnym zestawem, ale dla którego chcesz skorzystać ze schematu XML platformy .NET, sekcji konfiguracji i mechanizmów elementów konfiguracji itp. Oznacza to utworzenie
ExeConfigurationFileMap
obiektu , ładowanie danych w celu zidentyfikowania miejsca przechowywania pliku konfiguracyjnego, a następnie wywoływanieConfigurationManager
.OpenMappedExeConfiguration
aby otworzyć go w nowejConfiguration
instancji. To będzie wyciąć cię z ochrony wersji oferowanej przez mechanizm automatycznego generowania ścieżki.Statystycznie rzecz biorąc, prawdopodobnie używasz tej biblioteki w ustawieniach wewnętrznych i jest mało prawdopodobne, że będziesz mieć wiele aplikacji korzystających z niej na jednym komputerze / użytkowniku. Ale jeśli nie, jest coś, o czym należy pamiętać. Jeśli używasz jednego globalnego pliku konfiguracyjnego dla swojej biblioteki DLL, niezależnie od aplikacji, do której się ona odwołuje, musisz martwić się o konflikty dostępu. Jeśli dwie aplikacje odwołujące się do Twojej biblioteki działają jednocześnie, każda z własną
Configuration
otwartym obiektem, to kiedy jedna zapisze zmiany, spowoduje to wyjątek przy następnej próbie pobrania lub zapisania danych w drugiej aplikacji.Najbezpieczniejszym i najprostszym sposobem na obejście tego jest wymaganie, aby zestaw, który ładuje bibliotekę DLL, również podał pewne informacje o sobie lub wykrył je, badając domenę aplikacji zestawu odniesienia. Użyj tego, aby utworzyć strukturę folderów do przechowywania osobnych plików konfiguracji użytkownika dla każdej aplikacji odwołującej się do twojej biblioteki DLL.
Jeśli masz pewność, że chcesz mieć globalne ustawienia dla swojej biblioteki DLL, bez względu na to, gdzie jest do niej odniesienie, musisz określić jej lokalizację zamiast .NET automatycznie wymyślić odpowiednią. Musisz także być agresywny w zarządzaniu dostępem do pliku. Musisz buforować jak najwięcej, utrzymując
Configuration
instancję TYLKO tak długo, jak długo trwa ładowanie lub zapisywanie, otwierając bezpośrednio przed i usuwając zaraz po. I w końcu będziesz potrzebować mechanizmu blokującego, aby chronić plik, gdy jest on edytowany przez jedną z aplikacji korzystających z biblioteki.źródło
jeśli chcesz odczytać ustawienia z pliku konfiguracyjnego DLL, ale nie z aplikacji root webconcon lub app.config, użyj poniższego kodu, aby odczytać konfigurację w bibliotece dll.
źródło
Miałem ten sam problem i przeszukiwałem Internet przez kilka godzin, ale nie mogłem znaleźć żadnego rozwiązania, więc zrobiłem własny. Zastanawiałem się, dlaczego system konfiguracji .net jest tak nieelastyczny.
Tło: Chcę, aby mój plik DAL.dll miał własny plik konfiguracyjny dla ustawień bazy danych i DAL. Potrzebuję również app.config dla biblioteki Enterprise i jej własnych konfiguracji. Potrzebuję więc zarówno app.config, jak i dll.config.
To, czego nie chciałem robić, to przekazywanie wszystkich właściwości / ustawień z aplikacji do mojej warstwy DAL!
wygięcie „AppDomain.CurrentDomain.SetupInformation.ConfigurationFile” nie jest możliwe, ponieważ potrzebuję go do normalnego zachowania app.config.
Moje wymagania / punkty widzenia były następujące:
Wymyśliłem modyfikację pliku Settings.cs i wdrożyłem metodę, która otwiera ClassLibrary1.dll.config i odczytuje informacje o sekcji w prywatnym polu. Następnie zastąpiłem „this [string propertyName]”, więc wygenerowane Settings.Desginer.cs wywołują moją nową właściwość zamiast klasy podstawowej. Tam ustawienie jest odczytywane z listy.
Wreszcie jest następujący kod:
Musisz tylko skopiować ClassLibrary1.dll.config z katalogu wyjściowego ClassLibrary1 do katalogu wyjściowego aplikacji. Być może ktoś uzna to za przydatne.
źródło
Korzystając z Menedżera konfiguracji, jestem prawie pewien, że ładuje proces /
AppDomain
plik konfiguracji (app.config / web.config). Jeśli chcesz załadować określony plik konfiguracyjny, musisz poprosić o ten plik według nazwy ...Możesz spróbować:
źródło
ConfigurationManager.AppSettings zwraca ustawienia zdefiniowane dla aplikacji, a nie dla konkretnej biblioteki DLL, można uzyskać do nich dostęp, ale zostaną zwrócone ustawienia aplikacji.
Jeśli używasz dll z innej aplikacji, ConnectionString powinien znajdować się w ustawieniach aplikacji.
źródło
Wiem, że to spóźnia się na imprezę, ale pomyślałem, że podzielę się rozwiązaniem, którego używam dla bibliotek DLL.
Jestem bardziej szkołą myślenia KISS, więc kiedy mam bibliotekę .NET DLL, która chce przechowywać zewnętrzne punkty danych, które kontrolują jej działanie lub kierunek, itp. Po prostu tworzę klasę „config”, która ma tylko właściwości publiczne które przechowują wszystkie potrzebne punkty danych i które chciałbym mieć możliwość kontrolowania zewnętrznego pliku DLL, aby zapobiec ponownej kompilacji w celu wprowadzenia zmian. Następnie używam serializacji XML .Net do zapisania i załadowania reprezentacji obiektowej klasy do pliku.
Istnieje wiele sposobów radzenia sobie z czytaniem i dostępem do nich, od Singletona, statycznej klasy narzędziowej, po metody rozszerzeń itp. Zależy to od struktury biblioteki DLL i metody, która najlepiej pasuje do biblioteki DLL.
źródło
masz rację, możesz odczytać plik konfiguracyjny dll. Walczyłem z tym przez jeden dzień, dopóki nie dowiedziałem się, że problem tkwi w moim pliku konfiguracyjnym. Zobacz mój kod poniżej. był w stanie uciec.
mój
Plugin1.dll.config
wyglądał jak poniżej;Dowiedziałem się, że w moim pliku konfiguracyjnym brakuje
<appSettings>
tagu, więc rozejrzyj się, twój problem mógł być inny, ale nie tak daleki od mojego.źródło
Ponieważ zestaw znajduje się w tymczasowej pamięci podręcznej, należy połączyć ścieżkę, aby uzyskać konfigurację biblioteki dll:
źródło
Jeśli korzystasz z bibliotek, które wyszukują wiele konfiguracji za kulisami, takich jak WCF, możesz rozważyć zrobienie tego:
Lub w PowerShell:
IMO ta technika ma zapach kodu i naprawdę nadaje się tylko do użytku w skryptach ad hoc. Jeśli chcesz to zrobić w kodzie produkcyjnym, być może nadszedł czas na przegląd architektoniczny.
NIE jest zalecane:
Jako ciekawostkę techniczną, oto wariacja na temat. Możesz utworzyć konstruktora statycznego w jednej z klas znajdujących się w bibliotece DLL i stamtąd wywołać to wywołanie. Nie poleciłbym tego robić, chyba że w ostateczności.
źródło
Pełne rozwiązanie nie jest często spotykane w jednym miejscu ...
1) Utwórz plik konfiguracyjny aplikacji i nazwij go „twojaDllName.dll.config”
2) Kliknij prawym przyciskiem myszy plik konfiguracyjny utworzony powyżej w VS Solution Explorer, kliknij właściwości
--- ustaw „Kompilacja działania” = Treść
--- ustaw „Kopiuj do katalogu wyjściowego” = Zawsze
3) Dodaj sekcję appSettings do pliku konfiguracyjnego (twojaDllName.dll.config) z twojąNazwaKluczową iNazwaKluczowa
4) Dodaj System.Configuration do dll / class / project odniesienia
5) Dodaj instrukcje using do swojego kodu, w którym zamierzasz uzyskać dostęp do ustawienia konfiguracji
6) Aby uzyskać dostęp do wartości
7) radujcie się, działa
IMHO, należy tego używać tylko podczas opracowywania nowej biblioteki dll / biblioteki.
Plik konfiguracyjny kończy się świetnym odniesieniem, ponieważ gdy dodajesz dll's appSettings do faktycznej aplikacji.
źródło
Wygląda na to, że te pliki konfiguracyjne są bardzo mylące, ponieważ ich zachowanie zmienia się ze środowiska deweloperskiego na wdrożenie. Najwyraźniej biblioteka DLL może mieć własny plik konfiguracyjny, ale po skopiowaniu i wklejeniu biblioteki dll (wraz z plikiem konfiguracyjnym) w innym miejscu cała sprawa przestała działać. Jedynym rozwiązaniem jest ręczne scalenie plików app.config w jeden plik, który będzie używany tylko przez exec. Na przykład myapp.exe będzie miał plik myapp.exe.config, który zawiera wszystkie ustawienia wszystkich bibliotek dll używanych przez myapp.exe. Używam VS 2008.
źródło
Znalazłem dobre rozwiązanie tego problemu. Używam VS 2008 C #. Moje rozwiązanie polega na użyciu odrębnych przestrzeni nazw między wieloma plikami konfiguracyjnymi. Rozwiązanie opublikowałem na moim blogu: http://tommiecarter.blogspot.com/2011/02/how-to-access-multiple-config-files-in.html .
Na przykład:
Ta przestrzeń nazw odczytuje / zapisuje ustawienia dll:
Ta przestrzeń nazw odczytuje / zapisuje ustawienia exe:
W artykule wymieniono kilka zastrzeżeń. HTH
źródło
Jak mówi Marc, nie jest to możliwe (chociaż Visual Studio pozwala na dodanie pliku konfiguracji aplikacji w projekcie biblioteki klas).
Możesz sprawdzić klasę AssemblySettings, która wydaje się umożliwiać pliki konfiguracyjne zestawu.
źródło
W tym poście omówiono podobny problem i rozwiązano mój problem. Jak dynamicznie ładować osobny plik ustawień aplikacji i scalać z bieżącymi ustawieniami? może pomóc
źródło
W przypadku biblioteki dll nie powinno to zależeć od konfiguracji, ponieważ konfiguracja jest własnością aplikacji, a nie biblioteki dll.
Wyjaśniono to tutaj
źródło
możesz użyć tego kodu:
źródło