Dodatek ArcMap z app.settings nie rozpoznaje zmian app.config?

14

Opracowałem dodatek ArcMap, który wymaga pliku konfiguracyjnego. Po dłuższej chwili próbowania odczytania wartości konfiguracji z pojedynczego pliku App.Config (i zawsze uzyskanie wartości null) uważam, że dodatek nie może odczytać wartości stąd, ponieważ jest to biblioteka klas, i szuka aplikacji wywołującej (ArcMap) plik konfiguracyjny, gdy pytam o wartość klucza (stąd null).

Aby obejść ten problem, użyłem pliku App.Settings, który aplikacja może dobrze odczytać. Utworzenie tego również wprowadza do środowiska plik App.Config, a Visual Studio wydaje się utrzymywać synchronizację dwóch plików podczas programowania.

Teraz, gdy dodatek jest wdrażany, muszę mieć możliwość zmiany wartości konfiguracyjnych (np. Lokalizacji pliku dziennika). Próbowałem otworzyć / rozpakować plik .esriaddin i zaktualizować tam plik App.Config, ale dodatek zachowuje te same wartości konfiguracyjne, które miał podczas kompilacji. Wiem, że nowe wartości App.Config są zachowywane w pliku .esriaddin, ponieważ mogę je wyświetlić ponownie po zamknięciu archiwum.

Czy ktoś zna niezawodny sposób skonfigurowania dodatku i zezwala na aktualizację tej konfiguracji po wdrożeniu? Wszelkie sugestie są bardzo mile widziane, ponieważ wydaje się śmieszne, że potrzebuję do tego niestandardowego pliku konfiguracyjnego.

Wartości App.Settings są na poziomie aplikacji, a obecnie zarówno App.Settings, jak i App.Config mają działanie kompilacji: brak / nie kopiuj.

tomfumb
źródło

Odpowiedzi:

8

Wymyśliłem, jak skonfigurować dodatek.

Plik dodatek w ... Documents \ ArcGIS \ AddIns \ Desktop10.0 ... zostaje rozszerzony każdym razem ładunki ArcMap, więc jedynym miejscem, które JAKIEKOLWIEK pliki konfiguracyjne osadzone w addin można edytować znajduje się tutaj. Nie eksperymentowałem z użyciem kluczy rejestru ani z dedykowanym katalogiem konfiguracji dodatków, ponieważ wydawało się to przesadą.

W końcu użyłem pliku app.config (ponieważ nawet jeśli jest używany z biblioteką klas, która ignoruje plik konfiguracyjny, to nadal zmienia nazwę zgodnie z zespołem i automatycznie dołącza do archiwum dodatków) dla moich ustawień. W oparciu o powyższy link użyłem następującej klasy konfiguracji

...

    public AppConfig()
    {
        try
        {
            ExeConfigurationFileMap map = new ExeConfigurationFileMap();
            map.ExeConfigFilename = this.GetType().Assembly.Location + ".config";
            config = ConfigurationManager.OpenMappedExeConfiguration(map, ConfigurationUserLevel.None);
        }
        catch (Exception)
        {
            ...
        }
    }

    private string getValue(string key) 
    {
        return config.AppSettings.Settings[key].Value;
    }

...

Aby edytować konfigurację po wdrożeniu dodatku, musiałem zamknąć ArcMap, otworzyć plik .esriAddIn za pomocą winrar, przejść do \ install i otworzyć plik konfiguracyjny, edytować go, zamknąć edytor, a następnie pozwolić winrar na aktualizację pliku w archiwum. Następnie ładuję ArcMap, zmiana wchodzi. Irytująco jest to jedna z pierwszych rzeczy, które próbowałem, ale myślę, że miałem problemy, ponieważ edytor pliku konfiguracyjnego był nadal otwarty, gdy Winrar zaktualizował archiwum.

tomfumb
źródło
Czy ostatnio wystąpiły jakieś błędy związane z OpenMappedExeConfiguration? Korzystałem z podobnego podejścia, które działało dobrze, aż kilka dni temu przestało działać, być może po zainstalowaniu niektórych aktualizacji systemu Windows. Zobacz moje pytanie StackOverflow .
blah238,
@ blah238 Przez jakiś czas nie testowałem tego dodatku i nie mam teraz okazji. Jeśli jednak możesz podsumować swoje ostatnie aktualizacje systemu Windows / .NET, zobaczę, czy moje (Win7) pasują, i dam ci znać
tomfumb
Jedyną, którą uznałem za odpowiednią, była aktualizacja zabezpieczeń .NET 4 . Nie jestem pewien, czy to również może wpłynąć na .NET 3.5, na który celuję.
blah238
Do twojej wiadomości, skończyłem na ponownym zapisaniu logiki konfiguracji mojego dodatku, aby użyć tradycyjnej (de) serializacji XML zamiast systemu konfiguracji .NET, którego głównym rysunkiem było to, że plik .config jest automatycznie wyodrębniany wraz z zestaw z pliku .esriAddin - coś, o czym nie mogę, o ile wiem, zrobić z dowolnym plikiem XML - ale dla moich celów zdecydowałem, że tak naprawdę nie muszę dostarczać domyślnej konfiguracji, tylko trwam ustawienia specyficzne dla użytkownika). Chciałbym jednak wiedzieć, czy wpływa to również na innych programistów dodatków.
blah238,
Pogrzebując nieco więcej przy użyciu podejścia .config i Fusion ujawnia, że ​​ESRI używa Assembly.LoadFrom () do ładowania zestawów dodatków. Z tego, co przeczytałem, jest to sprzeczne z najlepszą praktyką, która polega na konfigurowaniu oddzielnej AppDomain dla dodatków, i może wyjaśniać, dlaczego ConfigurationManager nie zawraca sobie głowy szukaniem zestawu prawidłowej lokalizacji. Nie rozumiem, dlaczego musi nawet szukać zestawu ponownie, gdy został już załadowany do domyślnej domeny AppDomain. Mogę tylko założyć, że aktualizacja zabezpieczeń .NET zaczęła wymuszać częstsze sprawdzanie lokalizacji zespołów.
blah238,
6

Pożyczając od podobnej odpowiedzi , możesz użyć tego w swoim dodatku:

string configPath = System.IO.Path.Combine(this.GetType().Assembly.Location,"Config.xml");
Kirk Kuykendall
źródło
Dzięki za wskazówkę, ścieżka utworzona przez powyższe jest nieprawidłowa, ponieważ daje ... / addInName.dll / config.xml, ale doprowadziła mnie do właściwej ścieżki. Teraz używam nieco prostszegothis.GetType().Assembly.Location + ".config"
tomfumb
2

Standardowy plik konfiguracyjny .NET dotyczy aplikacji, a nie biblioteki. Oznacza to, że gdy dodatek działa w procesie ArcMap, ustawienia konfiguracji należy określić w ArcMap.exe.config, który należy umieścić oprócz ArcMap.exe.

Jest to oczywiście nie zawsze możliwe w środowisku produkcyjnym, a także narusza izolację dodatków, co jest jednym z powodów, dla których dodatki zostały wprowadzone w pierwszej kolejności.

Będziesz musiał zapisać swoje ustawienia inaczej, albo we własnym pliku konfiguracyjnym (jak wskazano w odpowiedzi Kirka), albo w rejestrze systemu.

Możesz monitorować zmiany w pliku konfiguracyjnym na różne sposoby, na przykład wykorzystując klasę FileSystemWatcher .

Petr Krebs
źródło
1

Odpowiedź Kirk Kuykendall nie działa dla mnie, ponieważ przechowywane wskazując samego .dll. Użyłem następujących do wskazania pliku konfiguracyjnego

System.IO.StreamReader file = new System.IO.StreamReader(System.IO.Path.GetDirectoryName(this.GetType().Assembly.Location) + "\\config.cfg");
Evan Parsons
źródło
0

Chociaż nie patrzyłem na nowy model dodatku ESRI, to, co zrobiłem i widziałem, że zrobili to inni, jest użytkownik UserHive w rejestrze. Następnie możesz mieć ekran w swoim dodatku, aby zaktualizować potencjalne wartości, których potrzebujesz.

Korzystanie z pliku App.config wymaga całkowitego zrestartowania aplikacji / rozszerzenia w celu odczytania nowych wartości; podczas gdy łatwiej jest robić aktualizacje w czasie rzeczywistym z rejestru.

DEWright
źródło
0

Możesz spróbować zmodyfikować kopię pliku konfiguracyjnego znajdującego się w pamięci podręcznej zestawu dodatków . Uważam, że esriaddin jest rozszerzany tylko raz przez ArcGIS. Dlatego kolejne modyfikacje nie mogą być użyte (choć powinno zauważyć, że plik esriaddin jest nowszy niż jego pamięć podręczna).

Vista / 7: C: \ Users \\ AppData \ Local \ ESRI \ Desktop10.0 \ AssemblyCache

XP: C: \ Documents and Settings \\ Ustawienia lokalne \ Dane aplikacji \ ESRI \ Desktop10.0 \ AssemblyCache

James Schek
źródło
Ciekawa sugestia, ale niestety nie miało to znaczenia. Plik konfiguracyjny w katalogu AssemblyCache jest nadpisywany po uruchomieniu ArcMap - zmieniłem plik konfiguracyjny tutaj i w AddIn w ... \ Documents \ ArcGIS \ AddIns \ Desktop10. 0, więc nie mam pojęcia, skąd pochodzi wartość zastępowania!
tomfumb
Doceń dane wejściowe, ale wygląda na to, że plik .esriAddIn w Documents \ ArcGIS \ AddIns \ Desktop10.0 \ ..... faktycznie jest wyodrębniany przy każdym ładowaniu aplikacji, więc wszystkie zmiany w pamięci podręcznej zestawu dodatków są tracone.
tomfumb