좋아, 내가 가진 것 :

Visual Studio 2010 RC (W7 x64)는 새로운 프로젝트 유형의 Silverlight 응용 프로그램을 시작했습니다. ASP.NET 웹 응용 프로그램 프로젝트에서 Silverlight 응용 프로그램 호스팅 Silverlight 버전 3.0. LinqToSQL 클래스, WCF 서비스, Winform Tester 응용 프로그램 (프로젝트의 솔루션) 및 몇 개의 클래스 (솔루션의 프로젝트)가 추가되었습니다.

어제 갑자기 나는 '브레이크 포인트가 현재 맞지 않을 것입니다. 이 문서에 대한 기호가로드되지 않았습니다. ' 메시지는 IDE에 표시되지만 웹 응용 프로그램에만 영향을 미칩니다. Silverlight 및 Winform App을 디버깅 할 수 있습니다.

내가 메시지를 없애려고 시도한 것 :

• Visual Studio 설정 재설정
• 모든 \ Temporary ASP.NET 파일 폴더의 모든 파일을 제거했습니다 (32 비트 / 64 비트 및 프레임 워크 2.0 및 4.0마다 하나씩).
• Visual Studio 통합 웹 서버를 사용하여 디버그하려고했습니다. 일반적으로 IIS를 사용합니다. 솔루션의 프로젝트 출력에서 ​​모든 프로젝트 폴더의 모든 obj 및 bin 폴더를 삭제했습니다.
• 새로운 솔루션을 만들고이 새로운 솔루션에 모든 프로젝트를 추가했습니다
• 솔루션 suo 파일을 삭제했습니다
• VS 설치 문제인지 테스트하기 위해 새로운 ASP.NET 웹 응용 프로그램을 만들었습니다. =>이 새로운 프로젝트 / 솔루션을 디버깅 할 수 있습니다
• 컴퓨터를 여러 번 재부팅
• vs.net 설치 복구
• IISReset을 했어
• IIS에서 웹앱 제거
• 웹 응용 프로그램의 프로젝트 속성에서 가상 디렉터리 만들기 단추를 사용하여 IIS에서 새 웹 응용 프로그램을 만들었습니다.
• 모든 프로젝트의 프레임 워크 버전을 3.5에서 4.0으로 변경
• 두 번째 컴퓨터에서 솔루션을 열었습니다 => 동일한 동작
• 버그 / 유사한 문제에 대해 Microsoft Connect 크롤링
• SPENT 7 시간

그래서 이것은 내 인생에서 두 번째로 발생합니다. 지난번에 임시 ASP.NET 파일 폴더를 삭제하여 해결했지만 이번에는 도움이 필요합니다.

솔루션-> 속성을 ​​마우스 오른쪽 버튼으로 클릭하십시오.

공통 속성-> 시작 프로젝트에서 확인하십시오.

여러 개의 시작 프로젝트를 선택하십시오

디버그해야하는 프로젝트에서 조치 시작을 선택하십시오.

나는 같은 문제가 있었고 인터넷 검색 후 이에 대한 두 가지 일반적인 해결책을 찾았습니다.

1. .Web 프로젝트에서 Silverlight 디버거가 활성화되어 있는지 확인하십시오. 프로젝트 속성을 열고 "웹"탭에서 Silverlight 디버거를 선택하십시오.

2. Visual Studio를 다시 시작하고 모든 bin 및 obj 폴더를 삭제하십시오.

그러나 이것들 중 어느 것도 나를 위해 일하지 않았습니다 . 그런 다음 누군가 브라우저 대신 IE를 사용해보십시오. 이로 인해 디버깅 및 중단 점이 다시 작동했습니다!

편집하다:

나중에 IE9가 작동하지 않는 데 어려움을 겪었습니다. 잘못된 프로세스에 연결되어 있기 때문입니다. 매번 올바른 IE 프로세스에 수동으로 연결하는 대신 깔끔한 트릭을 발견했습니다 .

• .Web 프로젝트 (.html 또는 .aspx)에서 생성 된 페이지 중 하나를 마우스 오른쪽 단추로 클릭하십시오.
• "찾아보기 ..."를 클릭하십시오
• IE를 기본 브라우저로 설정 (Visual Studio의 브라우저 선택에만 영향을 미침)

이제 Visual Studio는 .Web 프로젝트를 실행할 때 IE를 시작하고 올바른 프로세스에 연결합니다. 그렇게해야합니다.

이 특정 오류가 발생하면 Visual Studio에서 어셈블리를로드하는 폴더가 웹 응용 프로그램이 실행되는 폴더와 다른 것으로 나타났습니다.

즉, 응용 프로그램 서버가 응용 프로그램을

C:\dev\MyApplication\bin 

하지만 Visual Studio는

C:\dev\MyOtherApplication\bin (or something along those lines, anyway).

참고-여러 가지 이유로, 대부분의 사람들이 사용하는 dinky standalone 기즈모 대신 IIS를 응용 프로그램 호스트로 사용하여 디버깅을 수행합니다. 이것은 내 대답의 유용성에 영향을 줄 수 있습니다!

업데이트 :

IIS의 경우 응용 프로그램 서버 디렉토리 (예 : C:\dev\MyApplication위)는 웹 응용 프로그램에 대해 구성된 실제 디렉토리 입니다. 이는 응용 프로그램의 기본 설정을 변경하여 제어 할 수 있습니다.

Visual Studio의 경우 디버깅 디렉토리 ( C:\dev\MyOtherApplication위)는 svc파일 이있는 디렉토리 이며 일반적으로 csproj프로젝트 파일 과 동일한 디렉토리 입니다.

문제는 디버그 구성에서 속성-> 빌드-> 코드 최적화 확인란이 설정되어 있다는 것입니다. 전원을 끄고 다시 빌드하고 디버깅하면 정상적으로 작동했습니다.

당신이 직면 한 이유는 PDB ( "PDB는 프로그램 데이터베이스, 프로그램에 대한 디버깅 정보를 저장하기위한 독점 파일 형식 (Microsoft에서 개발))를 의미하지 않기 때문입니다. 이는 몇 가지 이유 때문일 수 있습니다 :

1- Bevan이 말했듯이 다른 응용 프로그램을 디버깅 중일 수 있습니다!

2- 같은 응용 프로그램의 다른 버전을 디버깅하고 있습니다. 예를 들어, 이전에 빌드 된 애플리케이션을 빌드하지 않고 디버깅하기 위해 현재 버전의 코드를 첨부했습니다.

솔루션을 청소 또는 재 구축하면 이러한 문제가 해결됩니다.

문제가 귀하의 것이 아닌지 확인하려면 VS 2008을 사용하여 동일한 응용 프로그램을 디버깅하십시오 (VS 2010의 버그 일 수 있습니다. 아직 베타 버전입니다!).

나는 같은 문제가 있었고 프로젝트를 디버깅하고 있었고 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 "새 디버그 인스턴스"를 선택해야했다. 나는이 작업을 한 번만 수행 한 다음 정상적으로 작동했습니다.

이 오류는 때때로 발생하고 나에게도 항상 발생하며 관련 어셈블리에 대한 프로젝트 설정을 항상 추적 할 수 있습니다. 코드가 중단 점을 준수하지 않거나 중단 점을 설정할 때까지 어떤 어셈블리에 심볼이로드되었는지 알기 위해 "대기"할 필요는 없습니다.

디버그 모드에서 프로젝트를 실행하면 출력 창에 다음과 같이 심볼이로드 된 어셈블리가 표시됩니다 (새 탭에서 이미지를 열어야 할 수도 있음).

따라서이 경우 BASD.Core.Data.dll에는 심볼이로드되지 않습니다. 그런 다음이 어셈블리의 프로젝트 설정을 심볼로드를 관리 한 다른 어셈블리의 프로젝트 설정과 비교하여 심볼을로드하는 이유와로드하지 않는 이유를 알아낼 수 있습니다.

"나를 위해"그러나 "매번"이 발생하면 디버그 정보가 생성되지 않기 때문입니다. 그래서 (C #) 프로젝트에서 프로젝트 속성> 빌드> 고급을 엽니 다.

따라서 Basd.Core.Data.dll 위의 기호, 즉 고급 빌드 설정은 다음과 같습니다.

Basd.Core.Configuration.dll 즉, 중단 점을 설정하고 중단 할 수있는 어셈블리의 설정은 다음과 같습니다.

그래서 첫 번째 프로젝트가 아닌 후자의 프로젝트에서 디버그 정보를 출력하므로 Basd.Core.Configuration.dll의 중단 점에 도달 할 수 있습니다.

또한 주어진 .dll에 대한 프로젝트의 bin 폴더에 .pdb 파일을 가지고있는 것만으로는 충분하지 않습니다. 시간이 오래되어 Visual Studio에서 .dll의 유효한 기호 파일로 선택하지 않았기 때문입니다. 당신은 단계적으로 노력하고 있습니다.

또한 빌드 구성을 변경하면 빌드 정보 설정과 기호를 가져 오는 위치가 변경 될 수 있습니다.

(이 경우 릴리스 모드에 있지만 방법이 여전히 적용됨을 알고 있습니다)

프로젝트 속성-> 빌드-> 고급으로 이동하십시오 ...

"출력"섹션의 디버그 정보 드롭 다운에서 "전체"를 선택하십시오.

RELEASE 모드가 아니라 DEBUG 모드에서 프로그램을 실행 중인지 확인하십시오.

디버그 -> 프로세스에 연결 ->
선택 디버그에게 이러한 코드 유형 : 옵션 ->
선택 관리 V3.5, 3.0, 2.0 또는 관리 V4.5을, 4.0

방금 Silverlight 응용 프로그램 배포에 따라이 문제를 해결했습니다 . (이 답변은 다른 답변과 중복되지만 더 자세히 설명하려고 노력할 것입니다.)

문제는 빌드 / 시작시 Silverlight 응용 프로그램이 웹 응용 프로그램에 제대로 배포되지 않았을 가능성이 큽니다. 이것은 참조하는 문제입니다. 이해하기는 쉽지만 처음 접했을 때는 분명하지 않습니다.

다른 프로젝트 참조와 마찬가지로 참조 된 프로젝트의 출력은 참조 프로젝트의 bin 폴더 로 복사 하여 디버그해야합니다. 클래스 라이브러리의 경우 마우스 오른쪽 버튼을 클릭하고 '참조 추가 ...'를 선택하면 이런 일이 발생합니다. Silverlight의 경우 프로젝트 속성을 통해 참조를 추가해야합니다.

• 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 '속성'을 선택하십시오.
• 왼쪽의 'Silverlight Applications'탭을 선택하십시오
• '추가 ...'버튼을 누르고 대화 상자에서 Silverlight 프로젝트를 선택하십시오.

이렇게하면 호스팅 웹 앱에서 Silverlight 응용 프로그램에 대한 참조가 추가 xap되고 빌드 또는 배포시 파일이 웹 응용 프로그램으로 복사됩니다. 즉, 현재 Silverlight 앱과 해당 디버그 파일은 디버깅중인 응용 프로그램 내에 있으며 코드를 단계별로 실행할 수 있습니다.

웹 프로젝트를 디버깅하는 경우 web.config 파일에 debug = "true"속성이 설정되어 있는지 확인하십시오.

<system.web>
    <compilation debug="true"   .../>

Windows 7에서 동일한 문제가 발생하여 DLL 정리, 모듈 목록 조사, "Just My Code"끄기 등 모든 것을 시도 했습니다.

"관리자 권한으로"Visual Studio를 실행 한 후에 문제가 해결되었습니다. 솔직히 왜 Microsoft가 "관리자 권한으로"실행되고 있지 않다고 경고 하지 않았 습니까? 작업 시간을 절약 할 수 있습니다.

나에게 문제는 프로젝트 설정의 빌드 탭에서 "코드 최적화"를 활성화했다는 것입니다.

같은 문제가 있었다

어떤 이유로 DLL 중 하나가 GAC에 등록되었으므로 항상 코드와 다른 버전을 가졌습니다.

GAC에서 제거하면 문제가 해결되었습니다.

Visual Studio 2010을 사용하지 않고 Visual Studio 2008을 사용하는 읽기의 경우이 오류가 발생합니다. 위의 답변은이 상황에서 도움이되지 않았으므로 경험을 공유하고 있습니다.

디버깅을 위해 ASP.NET 개발 서버를 사용하여 디버깅하지 않고 w3wp.exe 프로세스에 연결하여 Visual Studio 2008에서 IIS 웹 응용 프로그램을 디버깅하는 경우 (문제는 디버깅으로 시작)

Visual Studio가 여전히 오래된 IIS 프로세스의 dll에서 심볼 파일 (디버깅 중 사용 된 파일)을 참조하고있을 수 있습니다. 그리고 해당 심볼 파일은 .NET 소스 코드 재 컴파일에 의해 다시 작성되었지만 IIS 프로세스는 여전히 기존 심볼 파일을 참조하고 있습니다.

고치다:

Visual Studio에서 디버깅을 중지하고 웹 응용 프로그램을 다시 시작한 다음 프로세스에 다시 연결하십시오. 그런 다음 중단 점이 노란색 (이 오류가 표시 될 때)에서 다시 빨간색으로 바뀌어야합니다.

=========================

더 시도해야 할 것들 (오늘날 새로운 상황이 발견됨) :

한 번에 하나씩 아래 링크의 각 글 머리 기호를 수행하지만 시도 할 때마다 아래 단계를 반복하십시오.

http://carnotaurus.philipcarney.com/post/4130422114/visual-studio-debugging-issue-with-files-of-the-same

1.) Visual Studio에서 디버깅 중지 (빨간색 사각형 아이콘 누름)
2.) 클린 솔루션
3.) 솔루션 빌드
4.) [BULLET 명령 삽입]
5.) 도구> 프로세스에 연결 (또는 디버깅으로 시작)
6.) 연결하려는 프로그램을 시작하고 코드에 부딪 히도록 실행하십시오.

6 설명 :

nunit.exe에 연결 한 경우 NUnit을 열고 테스트를 실행하여 중단 점에 도달하십시오.

w3wp.exe (IIS 사이트)에 연결 한 경우 브라우저에서 사이트를 열고 중단 점에 도달하는 페이지로 이동하십시오.

편집하다:

오늘 나는 시작 프로젝트로 설정되지 않은 프로젝트에서 디버깅을 시도하면 이것을 보여줍니다. w3wp.exe 프로세스에 연결하면 시작 프로젝트로 설정된 프로젝트에서 디버깅을 생각합니다. 해결하려면 웹 응용 프로그램 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 "프로젝트 시작으로 설정"을 선택하십시오. 그런 다음 프로세스에 다시 연결하십시오.

시나리오는 다음과 같습니다. 특정 프로젝트는 시작 프로젝트입니다 (예 : Main 방법). 해당 프로젝트는 솔루션의 다른 프로젝트를 참조하고 있습니다. 다른 프로젝트의 중단 점이 맞지 않습니다.

빠른 솔루션 : 솔루션을 빌드 할 때 시작 프로젝트의 빌드 출력 경로 (일반적으로 bin \ Debug)를 확인하십시오. 참조하는 프로젝트의 DLL 및 PDB 파일을 확인하십시오. 마지막 수정 날짜가 솔루션을 마지막으로 빌드 한 날짜인지 확인하십시오. 그렇지 않은 경우 각 프로젝트의 빌드 출력 경로에서 시작 프로젝트 빌드 출력 경로로 복사하십시오. 예를 들면 다음과 같습니다.

프로젝트 A에는 메인이 있습니다. 프로젝트 B를 참조합니다. 중단 점이 프로젝트 B에서 적중되지 않습니다. DLL 및 PDB 파일을 프로젝트 B의 빌드 출력 경로에서 프로젝트 A의 빌드 출력 경로로 복사하십시오. 그런 다음 솔루션을 실행하십시오. 이제 브레이크 포인트에 도달합니다.

이제 프로젝트 A가 프로젝트 B의 DLL 및 PDB 파일을 복사하지 않는 이유를 알아야합니다. 여기에 대한 답변은 대부분의 시나리오를 다룹니다. 한 가지 시나리오는 프로젝트와 솔루션이 TFS에 올바르게 바인딩되어 있는지 확인하는 것입니다. 일부 프로젝트가 바인딩되었고 일부는 올바르게 바인딩되지 않았습니다. 그로 인해 문제가 발생했습니다. 일단 수정하면 문제가 사라지고 더 이상 DLL 및 PDB 파일을 복사 할 필요가 없었습니다.

필자의 경우 동일한 문제에 대한 해결책은 다음 단계 조합이었습니다.

1. 솔루션-> 특성 여러 시작 프로젝트 선택 디버그해야하는 프로젝트에서 시작 조치를 선택하십시오.
2. 서비스 참조에서 서비스를 제거하고 솔루션을 정리하십시오.
3. 서비스 프로젝트 재 구축
4. 다시 서비스 참조에 추가
5. 솔루션을 정리하고 다시 빌드하십시오.

Web.config 에서이 문제를 해결하려면 방금 추가해야했습니다. debug="true"

  <system.web>
    <compilation targetFramework="4.0" debug="true">

이 솔루션을 찾는 데 도움이 된 것은 디버깅하는 동안 모듈 창을보고 내 ASP.NET DLL에 대해로드 된 것을 보았습니다. 바이너리는 디버그 정보로 작성되지 않았습니다.

VS2013에서 웹 응용 프로그램에 대해 동일한 문제가 발생했습니다. 나에게 답은 솔루션의 빌드 구성을 업데이트하는 것이 었습니다.

1. 솔루션을 마우스 오른쪽 버튼으로 클릭하고 속성을 선택하십시오.
2. 디버그 구성을 선택하십시오.
3. 삼발이의 "구성 속성"에서 "구성"을 선택하십시오.
4. 디버깅하려는 각 프로젝트에 대해 "빌드"상자를 체크하십시오.

이렇게하면 모든 중단 점이 작동하기 시작했습니다.

알았어-여기 간다 :

( "silverlight 앱": 서버 프로젝트 "properties"의 "web"에서 silverlight가 선택되어 있는지 확인하십시오. 그래도 해결되지 않으면 아래에서 시도하십시오)

처음에 수행 : 먼저 실행 : devenv.exe / ResetSettings 및 1 : 최상위 메뉴에서 디버그 태그 클릭 2 : 옵션 및 설정 3 : "디버깅"및 "일반"에서 ".net 프레임 워크 소스 스테핑 사용"을 찾으십시오. 4 : 박스를 체크하십시오. 5 : 이제 모든 기호가 다운로드되고 재구성됩니다. :)

위의 후에 다시 발생하면 기호가있는 폴더를 지우십시오.

1 : 최상위 메뉴에서 디버그 태그를 클릭합니다. 2 : 옵션 및 설정을 클릭합니다. 3 : "디버깅"및 "기호"에서 "빈 심볼 캐시"버튼을 찾아 클릭합니다.

브라우저에서 웹 응용 프로그램 URL을 연 다음 VS.Net IDE에서 Tools-> AttachtoProcess를 사용하십시오.

그런 다음 aspnet_wp.exe에 연결하십시오.

디버거가 작동하기 시작합니다

레지스트리에서 .dll의 모든 인스턴스를 제거하고 로컬 드라이브에서 .dll의 모든 인스턴스를 수동으로 제거해야했습니다. 내 앱을 제거 / 다시 설치하면 중단 점이 발생합니다! 이 일을 반나절 낭비했다 :(.

폴더 의 .pdb파일 이름을 바꾸고 obj\debug깨끗한 솔루션을 만들고 다시 작성했습니다.
새 .pdb파일을 만들었고 중단 점을 올바르게 칠 수있었습니다.

같은 문제가 발생했습니다 .Visual Studio에서 디버깅 작업을 시도하는 데 많은 시간을 허비했습니다.

Nuget이되었습니다 .Newtonsoft.Json의 3 가지 버전이 있습니다 (7 개의 C # 프로젝트). 솔루션이 컴파일되었지만 디버깅 할 수 없었습니다.

Nuget의 패키지 관리자 콘솔에서 다음을 실행하여 문제를 해결했습니다.

PM> 업데이트 패키지 Newtonsoft.Json

내 WPF 응용 프로그램의 경우 응용 프로그램 폴더를 삭제하고 소스 제어에서 "최신 정보 얻기"를 다시 한 다음 다시 작성했습니다. 모든 중단 점은 현재 잘 작동합니다.

Silverlight Application Project를 시작 프로젝트로 설정하십시오. 프로젝트-> '시작 프로젝트로 설정을 마우스 오른쪽 단추로 클릭하십시오. 그런 다음 F5를 누르고 중단 점을 잡을 수 있는지 확인하십시오 ...

Silverlight 응용 프로그램을 변경할 때마다 브라우저에서 탐색 / 임시 데이터를 삭제하십시오.

유용 할 수있는 또 다른 일화

내 프로젝트 중 하나가 Release 출력 폴더에서 파일 참조를 사용할 때이 문제가 발생했습니다. 빌드 결과가 Goods 폴더에 배치되면이 릴리스 dll은 디버그 dll을 덮어 씁니다.

해결책은 csproj 파일을 확인하는 것이 었습니다. 내 참조의 HintPath는

<HintPath>..\..\Core\Goods\$(Configuration)\MyFramework.dll</HintPath>

그리고 아닙니다

<HintPath>..\..\Core\Goods\Release\MyFramework.dll</HintPath>

클라이언트에서 각 응용 프로그램 솔루션에 대해 대부분의 공유 어셈블리를 " 참조 "폴더에 복사 한 다음 솔루션의 " 솔루션 항목 " 및 " 프로젝트 " 로 솔루션에 추가 한 경우이 문제가 발생했습니다 .

아직 이유는 확실하지 않지만 일부는 디버깅 할 수 있지만 일부는 어셈블리의 참조 설정에서 올바른 전체 경로가 지정되었지만 그렇지 않습니다.

이 예측할 수없는 행동이 엄청나게 나를 미치게했다 :)

소스 코드가있는 프로젝트가 있는 " References "폴더 에서 모든 어셈블리를 제거하고 공유 어셈블리의 버전 정보를 매우 잘 추적 하여이 문제를 해결했습니다 .

내 문제가 어리석은 것을 제외하고 비슷한 문제가있었습니다 .2 개의 다른 포트에서 실행되는 내장 웹 서버 인스턴스가 2 개 있었고 고정 포트를 가리키는 프로젝트-> 속성-> 웹-> "시작 URL"이 있었지만 웹 앱은 실제로 해당 포트에서 실행되지 않았습니다. 그래서 내 브라우저는 1539를 참조하는 "시작 URL"로 리디렉션되었지만 코드 / 디버그 인스턴스는 포트 50803에서 실행되었습니다.

내장 웹 서버를 고정 포트에서 실행하도록 변경하고 해당 포트를 사용하도록 "시작 URL"을 조정했습니다. 프로젝트-> 속성-> 웹-> "서버"섹션-> "Visual Studio 개발 서버 사용"-> 특정 포트