Nie można debugować, choć symbole są załadowane

Zacznijmy od tego, że jest sobie folder, który fizycznie znajduje się w %APPDATA%\XXX i jest zmapowany jako dysk U. Dysk U jest dodany do zmiennej środowiskowej Path. Znajdują się tu biblioteki, z których korzysta Word.

Jedna z tych bibliotek to ABC.dll. W Output folder ma podany dysk U, w Debug -> Start Action -> Start external program: C:\Program Files (x86)\Microsoft Office\Office14\WINWORD.EXE

Word woła funkcje z niej w standardowy sposób:

#If VBA7 Then
    Private Declare PtrSafe Function GetData Lib "ABC" (ByVal test As String) As Variant
#Else
    Private Declare Function GetData Lib "ABC" (ByVal test As String) As Variant
#End If

Generalnie działa, ale nie wpada w breakpointy.
Breakpoint jest biały z czerwoną ramką i warningiem:

The breakpoint will not currently be hit. No executable code of the debugger's target code type is associated with this line.
Possible causes include: conditional compilation, compiler optimizations, or the target architecture of this line is not supported by the current debugger code type.

Na liście modułów dllka pojawia się dwa razy (w momencie wywołania kodu z niej). W path ma podaną ścieżkę do %APPDATA%, nie do dysku U (w obu pozycjach jest taka sama). Symbole są załadowane, również w obu pozycjach, również z %APPDATA%. Teoretycznie jest to prawidłowy plik symboli. Nie wydaje mi się, by inaczej podana ścieżka (ale do tego samego przecież pliku) miała tu znaczenie, jednak wolę podać wszystkie szczegóły.

Conditional compilation? Jeśli chodzi o #if, to w tym miejscu kodu tego nie ma.
Compiler Optimization jest w opcjach odhaczone (Build -> Optimize code).
Pozostaje wtedy target architecture of this line is not supported. Przyznam, że nie rozumiem, jak to by się mogło stać. Platform target to x86, target framework to 3.5.

Czy macie jakieś pomysły, co może być przyczyną takiego zachowania? Oczywiście próbowałam już czyścić solucję, restartować VS i ręcznie usuwać pliki z output folder.

Rozumiem że tam gdzie jest biblioteka ABC.dll jest ABC.pdb. A jak zrobisz bulid w Debug mode i skopiujesz ręcznie .pdb to dalej nie łapie breakpointów?

Rozumiem że tam gdzie jest biblioteka ABC.dll jest ABC.pdb.

Zgadza się. I ten własnie plik pdb jest załadowany.

A jak zrobisz bulid w Debug mode i skopiujesz ręcznie .pdb to dalej nie łapie breakpointów?

Ale gdzie go skopiować?

aurel napisał(a):

Ale gdzie go skopiować?

Tam gdzie jest ABC.dll, czyli podmień plik ABD.pdb. Wiem że to wydaje się głupie, ale czasem działa. :)

Ale nie mam skąd podmienić ;) Plik pdb tworzy się od razu tam gdzie trzeba, czyli przy ABC.dll.

A jak usuniesz foldery bin i obj i zrobisz rebulid to też nie łapie? :P

Niestety, usunięcie bin i obj nie pomogło. Folder bin to właściwie mi się nie tworzy (Output directory mam ustawiony na dysk U). Próbowałam również usuwać pliki z U (zarówno cleanem jak i ręcznie).