To pytanie ma znaczenie ponad moją własną sprawę, ponieważ każdy, kto ma zlokalizowaną aplikację i musi dostarczyć autonomicznego EXE, ma ten problem - będzie chciał użyć ILMerge (lub Costura lub jakiegoś rozwiązania homebrew), aby umieścić lokalizacyjne biblioteki DLL (lub dowolne inne). inny zestaw) do swojego EXE - ale gdy już to zrobią, nie mogą już debugować swojego kodu. Debuger VS po prostu odmówi przyjęcia oryginalnego pliku PDB wygenerowanego dla oryginalnego EXE, prawdopodobnie dlatego, że krok ILMerge aktualizuje sumę kontrolną lub zmienia identyfikator GUID.Jakikolwiek sposób, aby VS (2010) zaakceptował PDB po użyciu ILMerge/Costura do łączenia złożeń?
Zastanawiam się, czy jest jakikolwiek sposób obejścia tego ... może jakaś mało znana opcja ILMerge? Uderza mnie to jako bardzo powszechna i niepotrzebna utrata zdolności do debugowania.
Wierzę, że jedynym innym sposobem debugowania takiej aplikacji po lokalizacji jest zachowanie równoległej opcji kompilacji, która używa bibliotek DLL un-ILMerged, co jest w porządku, chyba że zdarzy się, że chcesz debugować sam kod lokalizacji (na przykład , ja) .. to naprawdę nie masz szczęścia. Czy ktoś może pomyśleć o innych opcjach?
Próbowałem również używać Costura, ale ponieważ biblioteki DLL lokalizacji zawierają zasoby o identycznej nazwie (i są identyczne z głównym źródłem informacji AppName.resource), można dodać tylko jedną taką bibliotekę DLL do Referencji: kolejne są niedozwolone . Czy jest jakiś sposób, żeby nakłonić Costurę do pracy? (jeśli może to działać, problem PDB może nie wystąpić, ponieważ kombinacja jest częścią wizualnej wersji studyjnej ..?)
Edycja: szukam pomysłów, które doprowadzą do PDB/EXE mecz. Rozumiem, że możesz zhackować pdb w edytorze szesnastkowym. Pytanie dotyczy przede wszystkim sposobów, aby system działał zgodnie z zamierzeniami.