Dlaczego punkt przerwania nie może zostać „trafiony” podczas debugowania dodatku ArcGIS 10?

Od czasu do czasu napotykam następujący problem:

Rozpoczynam debugowanie dodatku, a punkty przerwania są ignorowane. Prawie wydaje się, że komunikacja między IDE a komponentem nie działa.

Mój problem polega na tym, że ostatnim razem to rozwiązałem i teraz nie pamiętam, co zrobiłem, aby to naprawić.

Punkt przerwania nie zostanie obecnie trafiony. Do dokumentu nie załadowano żadnych symboli.

Częściowo problem, który mam, został już tutaj opisany , ale nie ma rozwiązania dla rzeczywistej awarii punktu przerwania.

Pamiętaj, że to zwykle działa.

Usunięcie bin i obj nie wydaje się działać.

Tym razem właśnie przywróciłem cały projekt z kopii zapasowej i zacząłem od nowa, ale chciałbym wiedzieć, jak to naprawić, jeśli jeszcze się z tym spotkam.

Oto nieoficjalne i wciąż niesprawdzone rozwiązanie od pracowników ESRI. (Podkreślili, że nie jest to oficjalne rozwiązanie)

Spróbuj usunąć z arcmap.exe.config, w katalogu bin.

To jest plik xml \ ArcGIS \ Desktop10.0 \ bin \ arcmap.exe.config.

2 lata i 2 wersje później i to wciąż stanowi problem. Właśnie skończyłem aktualizować / ulepszać wszystkie moje dodatki do 10.2 i ponownie natknąłem się na ten problem. Wdrożono WSZYSTKIE sugestie w tym poście i nic nie działało, ale odkryłem 1 dodatkowy możliwy problem . Niestety nie jestem pewien, czy to był winowajca, czy nie, ponieważ zaimplementowałem też większość innych możliwych poprawek w tym samym czasie.

Nowe odkrycie: zdałem sobie sprawę, że rozwijam dodatki od wersji 10 na tym samym komputerze i po ponownej instalacji nie zawsze wyczyściłem starsze dane ArcGIS. Stwierdziłem, że miałem starszą wersję dodatku winowajcy w poprzedniej wersji danych ArcGIS w C: \ Program Files (x86) \ ArcGIS. Ponieważ ArcGIS załaduje starsze dodatki, mógł wystąpić konflikt. Usunąłem wszystkie starsze dane aplikacji Arcgis (Desktop10.0, Desktop10.1), pozostawiając tylko Desktop10.2 i punkt przerwania ożył. Ponownie nie jestem w 100%, jeśli jest to rozwiązanie, ale może to być kolejny element na liście do sprawdzenia.

Widziałem ten szczególny problem nazywany „ostatecznym zabójcą produktywności” w innej witrynie i nie mogłem się zgodzić.

Podsumowując, oto moja aktualna lista spraw dotyczących „martwego” punktu przerwania:

1. Upewnij się, że faktycznie uruchomiłem dodatek. Uruchomienie debugera aplikacji nie wystarczy - punkt przerwania będzie wyświetlany jako „martwy”, dopóki nie uruchomię dodatku (przycisk, opcja menu itp.)

2. Usuń karmy OBJ i BIN z katalogu projektu.

3. Usuń zawartość assebmly chache: C: \ Users \ User \ AppData \ Local \ ESRI \ Desktop10.2 \ AssemblyCache

4. Usuń wszystkie dane starszego zestawu. (Jeśli bieżąca wersja to 10.2, usuń dane asemblera Desktop10.0, Desktop10.1). Nie ma dowodu, że to pomaga lub jest częścią problemu, ale nie ma powodu, dla którego te dane muszą istnieć, więc usuwam je na wszelki wypadek (C : \ Users \ User \ AppData \ Local \ ESRI)

5. Zgodnie z sugestią wsparcia ESRI; Zmień XML konfiguracji ArcCatalog i ArcMap (nie działał sam, kiedy próbowałem, ale kilka osób poleciło to jako rozwiązanie, w tym obsługę ESRI) Znajdź ArcCatalog.exe.config i ArcMap.exe.config w C: \ Program Files ( x86) \ ArcGIS \ Desktop10.2 \ bin Otwórz każdy plik xml w notatniku i usuń wiersz <supportedRuntime version="v2.0.50727"/> To około piątej linii

6. Usuń wszystkie starsze dane aplikacji ArcGIS z katalogu instalacyjnego. To działało dla mnie. (prawdopodobnie) Przejdź do: C: \ Program Files (x86) \ ArcGIS Usuń wszystkie oprócz bieżących folderów dla Desktop10.x (tj. Desktop10.0, Desktop10.1) Tylko bieżąca wersja Desktop powinna pozostać w tej lokalizacji.

7. Usuń i ponownie dodaj wszystkie odwołania do projektu, w tym odniesienia inne niż ESRI, ponownie zapisz, powtórz kroki 2 i 3, ponownie skompiluj, uruchom dbugger.

8. Restart komputera. (Te czasy działały w przeszłości) Okazało się również, że jest to jedno z zalecanych rozwiązań w przypadku przepełnienia stosu.

9. W Config.esriaddinx - zmień przycisk, aby zawierał onDemand = false: (sugestia Kirka - patrz wyżej) Nie działało to dla mnie osobiście.

10. Odbuduj projekt od podstaw. (To działało dla mnie w przeszłości.)

Dostałem to tylko wtedy, gdy miałem otwartą kolejną instancję ArcMap i zapomniałem ją zamknąć przed budowaniem / debugowaniem. Jeśli nie zamkniesz wszystkich wystąpień za pomocą zestawu, stary będzie nadal używany. Czy jakoś tak.

Ponieważ .NET Framework mojego projektu to 4.0, zmieniłem program na supportedRuntime version="v4.0.30319"ArcMap.exe.config i zauważyłem, że zmiana opóźniła problem. Pamiętałem również, że ArcMap ładuje również ArcCatalog, więc zmieniłem także ArcCatalog.exe.config na supportedRuntime version="v4.0.30319"i TAK !!! Znowu działa. Spędziłem cały dzień, próbując to naprawić i mam nadzieję, że to również dla ciebie zadziała.

Próbowałem przez chwilę powyższych sugestii i w końcu znalazłem rozwiązanie. Przechodząc do sedna, najpierw dam rozwiązanie, a następnie wyjaśnienie:

1. Otwórz Menedżera zadań. Zakończ proces dla dowolnej kopii pliku ArcMap.exe.

2. Otwórz Eksploratora Windows. Przejdź do C: \ Users \\ Ustawienia lokalne \ ESRI \ Desktop10 ..

3. Jeśli nie widzisz AssemblyCache, Organizuj> Opcje folderów i wyszukiwania> Widok> odznacz „Ukryj chronione pliki systemu operacyjnego (zalecane)”

4. W katalogach w AssemblyCache poszukaj tego, w którym znajduje się plik .dll.

5. Usuń .dll.

6. Odbuduj projekt i debuguj. Po aktywowaniu dodawania powinieneś zobaczyć odświeżenie zawartości pamięci podręcznej.

7. W razie potrzeby ponownie ukryj chronione pliki systemu operacyjnego.

Problem polegał na tym, że w folderze C: \ Users \\ Ustawienia lokalne \ ESRI \ DesktopX.X \ AssemblyCache \ było stare wystąpienie mojej biblioteki DLL, a także nie mogłem zobaczyć \ AssemblyCache, ponieważ nie zdawałem sobie sprawy to był ukryty plik systemu operacyjnego. Działała też instancja ArcMap zombie, a kiedy próbowałem początkowo usunąć bibliotekę DLL, została ona zablokowana. Podejrzewam, że problem spowodował przede wszystkim to, że nie do końca zamknąłem debugowanie sesji ArcMap przed ponowną kompilacją kodu i uruchomieniem kolejnej. Starej biblioteki DLL w pamięci podręcznej nie można było zastąpić, ponieważ stara instancja ArcMap nadal ją blokowała, a gdy nie zsynchronizowała się z nowym kodem, wersja buforowana nie była już aktualizowana. (Widzę według dat pliku, że .config, .pdb i .xml są aktualizowane, ale nie .dll.)

Miałem do czynienia z tym samym problemem, z moim własnym dodatkiem w zupełnie innym temacie i zbadałem następujące kwestie:

Najpierw uruchom debugowanie, a następnie w menu wybierz następujące okno Debuguj >> Windows >> Moduły, w którym możesz zobaczyć, które moduły zostały załadowane podczas uruchamiania debugowania. Jeśli nie widzisz tam swojego plikuAddIn.dll, to przynajmniej wiesz, że nie został załadowany przez studio. Jeśli widzisz tam i nie możesz umieścić tam punktu przerwania, Studio załadowało stary. Aby to sprawdzić, zmień nazwę zestawu we właściwościach projektu, odbuduj rozwiązanie, uruchom debugowanie, a zobaczysz tam załadowaną starą bibliotekę DLL. Nie wiem, skąd studio ładuje tę starą bibliotekę DLL.

Przejdź do Eksploratora rozwiązań i sprawdź porównanie plików „yourAddIn.Addin” i „yourAddIn - do testowania.AddIn” i mogą się one różnić. Studio używa tylko drugiego pliku w Menedżerze dodatków! Przy pierwszej zmianie Zmień również znacznik w nim, aby odwoływał się do poprawnej biblioteki DLL, możesz także sprawdzić znacznik. Dla mnie ustawiono z powrotem na 0 w pliku „yourAddIn - For Testing.AddIn”, więc zmieniłem go z powrotem na 1. (Jeśli usuniesz katalog bin swojego dodatku i uruchomisz studio, wypromuje cię i zapyta chciałbyś usunąć ten dodatek z listy dodatków! W tym momencie Studio ustawia LoadBehavior na 0.)

Po tych dwóch zmianach znów zaczął działać!

W Visual Studio stworzyłem nowy dodatek do Arcmap i dodałem do niego przycisk i pasek narzędzi. W rezultacie plik konfiguracyjny wygląda następująco:

<ESRI.Configuration xmlns="http://schemas.esri.com/Desktop/AddIns" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
  <Name>ArcMapAddin4</Name>
  <AddInID>{b6b350bb-084d-42b8-a44a-6dbb6a9f5906}</AddInID>
  <Description>Type in a description for this Add-in.</Description>
  <Version>1.0</Version>
  <Image>Images\ArcMapAddin4.png</Image>
  <Author>Kirk</Author>
  <Company>Microsoft</Company>
  <Date>8/15/2011</Date>
  <Targets>
    <Target name="Desktop" version="10.0" />
  </Targets>
  <AddIn language="CLR" library="ArcMapAddin4.dll" namespace="ArcMapAddin4">
    <ArcMap>
      <Toolbars>
        <Toolbar id="MyToolbar4" caption="MyToolbar4" showInitially="true">
          <Items>
            <Button refID="Microsoft_ArcMapAddin4_Button1"/>
          </Items>
        </Toolbar>
      </Toolbars>
      <Commands>
        <Button id="Microsoft_ArcMapAddin4_Button1" class="Button1" message="Add-in command generated by Visual Studio project wizard." caption="My Button" tip="Add-in command tooltip." category="Add-In Controls" image="Images\Button1.png" />
      </Commands>
    </ArcMap>
  </AddIn>
</ESRI.Configuration>

Stworzyłem trochę kodu w konstruktorze przycisku i umieściłem w nim punkt przerwania. Uruchomiłem w trybie debugowania i zobaczyłem, że zestaw nie został jeszcze załadowany:

Zmieniłem przycisk, aby zawierał onDemand = false:

Kiedy ponownie uruchomiłem arcmap, osiągnął punkt krytyczny. Zauważ, że jeśli pasek narzędzi jest wyłączony podczas uruchamiania, musisz go pokazać, aby wywołać konstruktora przycisków - więc pod pewnymi względami jest on nadal na żądanie.

Musiałem zmienić mój dodatek do arcCatalog, aby pasował do frameworka 4 z nową wersją ArcCatalog 10.1.
Właśnie skomentowałem wersję = „v2.0.50727” i odkomentowano „v4.0.30319”

W C: \ Program Files (x86) \ ArcGIS \ Desktop10.1 \ bin plik konfiguracyjny xml ArcCatlog.exe

zatrzymuje się teraz w punkcie przerwania

Wydaje się, że jest to ten sam problem z arcmap

Po migracji projektu ESRI ArcGIS 10 z jednego komputera na drugi napotkałem błąd polegający na tym, że komputer nie mógł załadować plików debugowania .pdb dla ArcMap.exe. Próbowałem każdej porady w tym poście bez powodzenia.

Następnie wykonałem następujące czynności:

Usunąłem odniesienia do wszystkich bibliotek Esri. * W każdym projekcie, który je zawierał, i ponownie dodałem je do projektu na nowym komputerze.

To w końcu dla mnie zadziałało. Jeśli ktoś natknie się tutaj na ten niejasny problem i wypróbował wszystko inne wymienione na tej stronie, spróbuj tego - jest to szybkie, łatwe i całkiem nieszkodliwe. Nie jestem do końca pewien, dlaczego trzeba to zrobić, domyślam się, że ma to związek z wyszukiwaniem bibliotek na maszynę.

Dotyczyło to projektu korzystającego z BaseCommands / Toolbars, a nie nowych dodatków. Korzystanie z ArcGIS 10.0 i .NET 3.5 z Visual Studio 2010 w systemie Windows 7 Pro.

Dla tych, którzy celują w .Net 4.0 Framework, następujące działało dla mnie.

1. Zgodnie z wieloma sugestiami zmodyfikuj ArcMap.exe.config i ArcCatalog.exe.config, aby docelowy system 4.0
   <?xml version="1.0" encoding="utf-8" ?> <configuration> <startup> <supportedRuntime version="v4.0.30319"/> <!--supportedRuntime version="v2.0.50727"/--> </startup>
   Z jakiegoś powodu ArcCatalog.exe.config wyglądał na zablokowany w celu modyfikacji. Obejrzałem go, kopiując i modyfikując w innym katalogu, a następnie zastępując go.
2. Następnie w Config.esriaddinx zmień język Addin na "CLR4.0"

Przychodzą mi na myśl dwie możliwe przyczyny:

1. Dodatek nie został poprawnie zarejestrowany, więc biblioteka DLL nie jest ładowana do debugowanego procesu ArcMap.

2. Twój projekt jest ukierunkowany na .NET 4. Zamiast tego spróbuj skierować się na .NET 3.5.

Jeśli kodujesz z wieloma projektami w tym samym rozwiązaniu Visual Studio, możesz napotkać sytuacje, w których Visual Studio (VS) „wyłącza” punkty przerwania i nie możesz przejść przez kod. Zdarzyło mi się to ostatnio, gdy nie mogłem wkroczyć w „zależny” projekt zestawu DLL, który został wywołany z mojego głównego projektu.

Ostrzeżenia VS sugerowały, że mój zestaw (DLL) był nieaktualny i nie pasował dokładnie do mojego kodu. Istnieją opcje VS, aby wyłączyć wymóg dopasowania kodu, ale intuicyjnie wydawało się to złym pomysłem i zostało poparte przez posty internetowe. Czytam wiele stron internetowych i są tam pewne ogólne sugestie.

W końcu przeszukałem wyjściową bibliotekę DLL z mojego zależnego komputera i znalazłem kilka starych kopii w różnych lokalizacjach na moim komputerze (prawdopodobnie z wcześniejszych eksperymentów i konfiguracji projektu). Więc usunąłem je wszystkie i od nowa przebudowałem swoje rozwiązanie. To naprawiło mój problem. Wydaje mi się, że mój obecny projekt w jakiś sposób przypadkowo powiązał jedną ze starych kopii i nie korzysta z najnowszej kompilacji umieszczonej w folderze debugowania.

To, co zadziałało, nie polegało na usunięciu pliku arcmap.config.exe, jak opisano w poście przez Jakuba powyżej, ale na ustawieniu znacznika „obsługiwaneRuntime” w tym pliku na poprawną wersję środowiska docelowego w programie Visual Studio, w moim przypadku:

<startup>
    <supportedRuntime version="v3.5"/>
</startup> 

W ramach wielu projektów ArcObjects opracowałem listę powodów, dla których debugowanie może nie działać w przypadku dodatków, rozszerzeń i poleceń (przed dodaniem). W szczególnej kolejności:

1. Jesteś w trybie wydania programu Visual Studio zamiast w trybie debugowania
2. Stare wersje narzędzia są nadal zarejestrowane w ArcMap / ArcCatalog, co uniemożliwia załadowanie wersji debugowania lub rejestrację innych narzędzi o tej samej nazwie
3. Projekt / rozwiązanie wymaga wyczyszczenia, a jeśli to konieczne, przejdź do \ bin i \ obj i usuń wszystkie pliki trwałe
4. W niektórych przypadkach punkty przerwania można trafić tylko po aktywacji narzędzia (na żądanie)
5. Jeśli nie zostaną osiągnięte żadne punkty przerwania, możliwe jest wystąpienie wyjątku w konstruktorze i narzędzie nigdy nie działa. Sprawdź, pokazując wszystkie wyjątki CLR w menu debugowania
6. Wpisy w C: \ Users \ <nazwa> \ Local Settings \ ESRI \ DesktopX.X \ AssemblyCache wymagają usunięcia

Wiele kroków wymaga ponownego uruchomienia ArcMap. Jeśli wszystko inne zawiedzie, ponowne uruchomienie maszyny jest łatwym wyjściem awaryjnym, ale tylko raz miałem różnicę.

To, co zadziałało, zostało opisane przez AnthonyWJones w /programming/7192361/silverlight-project-wont-enter-debug-mode : „Otwórz właściwości powiązanego projektu sieci Web. Wybierz kartę sieci Web. Przewiń do u dołu iw sekcji „Debugery” upewnij się, że „Silverlight” jest zaznaczone. ”

Raz lub dwa mi się to przytrafiło. Jeśli dobrze pamiętam, udało mi się uruchomić punkt przerwania, gdy dokonałem niewielkiej zmiany kodu, co oznaczało, że aplikacja została przebudowana. Co się stanie, kiedy zbudujesz lub przebudujesz swój projekt?

Nie mogę uwierzyć, że więcej ludzi nie ma tego problemu. Teraz napotykam na to prawie za każdym razem, gdy poprawiam i debuguję moje dodatki.

Żadne z wyżej wymienionych rozwiązań nie działa. Aby to naprawić, muszę usunąć cały projekt i przywrócić go z kopii zapasowej. To prowadzi mnie do przekonania, że ​​coś w danym projekcie uległo uszkodzeniu, ponieważ zwykle zaczyna się dziać, gdy ArcMap ulega awarii podczas debugowania.

Czy tworzysz swój projekt za pomocą Framework 4? Miałem ten sam problem, ale po przejściu na Framework 3.5 działa dobrze.

spróbuj wyczyścić i przebudować, a następnie uruchom bez debugowania, gdy aplikacja uruchomi, dołącz go w VS

Wiem, że to może brzmieć zbyt oczywisto, ale i tak wspomnę, że potrzebujesz odpowiedniej wersji programu Visual Studio. Na przykład ten problem może wystąpić w przypadku edycji ekspresowej danego roku, podczas gdy może działać z wersją ostateczną. Jeśli używasz powiedz 2010, spróbuj przejść do 2012. Następnie spróbuj przełączyć się z ekspresowej na ostateczną. Zrobiłbym to, jeśli jeszcze nie zrobiłeś problemów z ładowaniem symboli. ESRI zapewnia informacje na temat pobierania symboli do pamięci podręcznej, jak wspomniano w powyższym linku (Pomoc ArcObjects 10 .NET SDK). Może to jednak nie być konieczne. Upewnij się, że używasz odpowiedniej architektury .net również przed debugowaniem, na przykład .net 3.5 w starszych wersjach.