NET Microsoft Visual Studio 2005 사용 시 발생하는 문제

[whitebono]

Microsoft Visual Studio 2005 사용 시 발생하는 문제

이 문서에서는 Microsoft Visual Studio 2005 사용 시 발생할 수 있는 문제를 보여 줍니다.  설치, 제거, 복구 및 기타 설치 절차에 관련된 문제는 온라인 Visual Studio 2005 추가 정보를 참조하십시오.

베타 2와 RTM 간의 새로운 변경 내용 목록은 http://go.microsoft.com/fwlink/?LinkId=51223 (영문)을 참조하십시오.

1.  모든 Visual Studio 제품 관련 문제
2.  Microsoft .NET Framework
3.  스마트 장치 프로그래밍 기능
4.  소스 코드 제어 통합
5.  Crystal Reports
6.  Tools for the Microsoft Office System

1. Visual Studio

1.1   VC++ Visual Studio 2005 베타 2 프로젝트 파일이 열리지 않습니다. 

최종 버전의 Visual Studio 2005를 사용하여 현재 컴퓨터와 Visual Studio 설치 위치가 다른 컴퓨터에 마지막으로 로드된 베타 2 C++ 프로젝트를 연 경우나 프로젝트 경로가 변경된 경우 오류가 발생할 수 있습니다.

이 문제를 해결하려면

프로젝트 설정 파일을 편집합니다. 솔루션 탐색기에서 회색으로 나타나는 프로젝트 노드를 마우스 오른쪽 단추로 클릭하고 "<projectname>.vcproj 편집"을 선택하여 XML 편집기에 해당 파일을 표시합니다. InheritedPropertySheets 태그의 값을 "$(VCInstallDir)VCProjectDefaults\UpgradeFromVC70.vsprops"로 변경한 다음 프로젝트를 다시 로드합니다.

1.2   Windows 2000에서 "응용 프로그램 검증 도구를 사용하여 시작"을 사용하면 "응용 프로그램 검증 도구가 machine_name에서 실행되는 운영 체제에서 지원되지 않습니다. Windows XP 이상으로 업그레이드하십시오." 

Windows 2000에서는 응용 프로그램 검증 도구를 지원하지 않습니다.

이 문제를 해결하려면

Windows XP 이상으로 업그레이드합니다.

1.3   응용 프로그램 검증 도구를 사용하여 시작에서 "응용 프로그램 검증 도구에 machine_name컴퓨터에서 검색되지 않은 업데이트된 시스템 파일이 필요합니다. Windows 다운로드 센터에서 업데이트를 가져오시겠습니까?"라는 대화 상자가 표시됩니다. 

Visual Studio 설치에서는 응용 프로그램 검증 도구에 필요한 시스템 파일을 설치하지 않습니다.  필요한 버전의 파일이 컴퓨터의 운영 체제에 없으면 해당 파일을 업데이트해야 응용 프로그램 검증 도구를 사용할 수 있습니다.

이 문제를 해결하려면

대화 상자에서 ''예''를 선택하면 인터넷 브라우저가 열리고 Microsoft 다운로드 센터 사이트의 업데이트 링크가 표시됩니다. 업데이트 링크에서 필요한 업데이트를 설치합니다. 다음 링크를 사용하여 Microsoft 다운로드 센터에 액세스할 수도 있습니다.
http://go.microsoft.com/fwlink/?LinkId=49500

1.4   분산 시스템 디자이너의 도구 상자는 다시 설정되기 전까지 로컬 Windows 언어 설정을 반영하지 않습니다. 

사용자는 옵션& 대화 상자에서 로컬 Windows 언어를 사용하도록 Visual Studio를 설정할 수 있습니다. 그러나 분산 시스템 디자이너의 도구 상자는 다시 설정되기 전까지 이 설정을 반영하지 않습니다.

이 문제를 해결하려면

1) 모든 분산 시스템 디자이너(응용 프로그램 디자이너, 시스템 디자이너, 논리 데이터 센터 디자이너 및 배포 디자이너)를 닫습니다.
2) 도구 상자 내부를 마우스 오른쪽 단추로 클릭한 다음 도구 상자 다시 설정을 클릭합니다.
3) 사용할 분산 시스템 디자이너를 다시 엽니다.

1.5   Windows 98 및 Windows Me에서의 원격 디버깅  

문제 1:

Visual Studio 2005를 사용하여 Windows Server 2003 기반 도메인 컨트롤러가 있는 도메인에 속한 Windows 98 또는 Windows ME 컴퓨터를 기본 전송을 통해 원격으로 디버깅하는 경우 Windows 98/ME 컴퓨터를 시작한 다음 10분 정도 후에 다음 오류 메시지가 표시될 수 있습니다.

-------------------------
Microsoft Visual Studio
-------------------------
''<machinename>'' Microsoft Visual Studio 원격 디버깅 모니터에 연결할 수 없습니다. 액세스가 거부되었습니다.

원인: SMB(Server Message Block) 서명이 Windows Server 2003 기반 도메인 컨트롤러에서 활성화되어 있으며 필요합니다.

문제 2:

Windows XP 이상의 컴퓨터에서 Visual Studio 2005를 사용하여 Windows 98 또는 Windows ME 컴퓨터를 원격으로 디버깅하는 경우 다음 오류 메시지가 표시될 수 있습니다.

-------------------------
Microsoft Visual Studio
-------------------------
''<qualifier_name>'' Microsoft Visual Studio 원격 디버깅 모니터에 연결할 수 없습니다. 원격 컴퓨터의 Microsoft Visual Studio 원격 디버깅 모니터가 로컬 컴퓨터에 연결할 수 없습니다. DCOM 통신을 초기화할 수 없습니다. 도움이 필요하면 도움말을 참조하십시오.

원인: "DCOM에서 익명 로그온의 원격 액세스"가 Visual Studio 2005를 실행하는 컴퓨터에서 비활성화되어 있습니다.

이 문제를 해결하려면

문제 1:

1) SMB 서명이 활성화되지만 필요하지 않도록 도메인 컨트롤러 정책을 설정합니다.
이 방법에 대한 자세한 내용은 http://support.microsoft.com/?kbid=887429를 참조하십시오.
2) 도메인 컨트롤러를 다시 시작합니다.
3) Visual Studio 2005가 설치된 컴퓨터를 다시 시작합니다.
4) Windows 98/ME를 실행하는 컴퓨터를 다시 시작합니다.

문제 2:

Visual Studio 2005를 실행하는 컴퓨터에서 "DCOM에서 익명 로그온의 원격 액세스"를 허용하려면 다음 지침을 따르십시오.
1) 명령 프롬프트에서 dcomcnfg를 입력한 다음 Enter 키를 누릅니다. 구성 요소 서비스가 열립니다.
2) 구성 요소 서비스에서 구성 요소 서비스, 컴퓨터, 내 컴퓨터를 차례로 확장합니다.
3) 도구 모음에서 내 컴퓨터 구성 단추를 클릭합니다. 내 컴퓨터 대화 상자가 나타납니다.
4) 내 컴퓨터 대화 상자에서 COM 보안 탭을 클릭합니다.
5) 액세스 권한에서 제한 편집을 클릭합니다. 액세스 권한 대화 상자가 나타납니다.
6) 그룹 또는 사용자 이름에서 ANONYMOUS LOGON을 클릭합니다.
7) ANONYMOUS LOGON에 대한 권한에서 원격 액세스 확인란을 선택한 다음 확인을 클릭합니다.
8) 컴퓨터를 다시 시작합니다.

1.6   웹 서비스 공급자 끝점에서 F1 키를 누르면 "정보가 없습니다."가 표시됩니다. 

웹 서비스 공급자 끝점이 응용 프로그램 다이어그램에서 선택되어 있을 때 F1 키를 누르면 관련 도움말 항목을 찾을 수 없습니다.

이 문제를 해결하려면

도움말에서 "방법: ASP.NET 웹 서비스에 대한 작업 정의"를 검색합니다.

1.7   SDM 문서에 보안 설정으로 정의되지 않은 설정이나 사용자 지정 설정에 중요한 정보를 저장하면 안 됩니다. 

SDM 문서(.sdm 및 .ad 파일 등)에 보안 설정으로 정의되지 않은 설정이나 사용자 지정 설정에 저장된 중요한 정보는 해당 파일에서 일반 텍스트로 나타납니다.

이 문제를 해결하려면

설정 및 제약 조건 편집기를 사용하는 경우 SDM 문서에서 보안 설정으로 지정된 설정에만 중요한 정보를 저장합니다. 자세한 내용은 도움말에서 "방법: 응용 프로그램, 서버, 끝점 및 영역의 사용자 지정 설정 만들기" 및 "응용 프로그램 구현을 위한 고려 사항"을 참조하십시오.

1.8   Itanium(IA64) 기본 도구 명령 프롬프트 시작  

Itanium(IA64)에서 도구를 설치하면 Itanium(IA64) 기본 도구 명령 프롬프트를 시작할 수 있는 바로 가기가 만들어지지 않습니다.

이 문제를 해결하려면

Itanium(IA64) 기본 도구 명령 프롬프트는 다음과 같이 시작할 수 있습니다.
1) 시작에서 실행을 클릭합니다.
2) cmd를 입력합니다.
3) 명령 프롬프트에서 <Visual Studio 2005 설치 디렉터리>\VC\bin\vcvars64.bat를 입력합니다.

1.9   네트워크 공유에서 계측된 모듈의 프로파일링 및 실행이 지원되지 않습니다. 

기본 Visual Studio 설정을 사용하여 네트워크 공유에서 계측된 바이너리를 실행하면 처리되지 않은 예외가 발생합니다.

이 문제를 해결하려면

로컬 하드웨어 드라이브에 프로파일링할 바이너리나 프로젝트를 복사하거나 이동합니다.

1.10    ETW(Event Tracing for Windows)를 사용하여 IIS5.1에 대한 이벤트 프로파일링 데이터를 수집할 수 없습니다. 

IIS5.1을 대상으로 하는 응용 프로그램의 추적 프로파일링과 ETW 이벤트 수집의 활성화가 UI에서 자동으로 실패하고 명령줄에 오류 VSP1432가 보고됩니다.

1.11   IA64 프로파일링이 지원되지 않습니다. 

IA64 프로파일링은 더 이상 지원되지 않습니다.

1.12   독립 실행형 프로파일러에서 코드 검사를 지원하지 않습니다. 

독립 실행형 프로파일러 설치에서 코드 검사를 실행하려고 하면 처리되지 않은 예외가 발생합니다.

1.13   ASP.NET 응용 프로그램에 대해 코드 검사를 실행하면 web.config의 상태가 변경될 수 있습니다. 

ASP.NET 프로젝트에 대해 단위 테스트를 실행하면 테스트 엔진에서 web.config 파일을 수정해야 합니다. 때때로 이러한 파일이 정리되지 않기 때문에 이후의 테스트 실행과 응용 프로그램 실행에서 예외가 발생할 수 있습니다.

이 문제를 해결하려면

테스트 실행 중 만들어진 백업에서 원래 web.config 파일을 복원합니다.

1.14   ReportViewer 컨트롤에 대한 지원이 Windows 98에서 제한됩니다. 

Windows Forms ReportViewer 컨트롤이 Windows98에서 실행되는 응용 프로그램에서 사용되는 경우 컨트롤 지원이 제한됩니다. 이 컨트롤을 사용하면 SQL Server 2005 Reporting Services 보고서 서버에서 이전에 게시된 보고서만 볼 수 있으며, 로컬 처리 모드에서 클라이언트 보고서 정의(.rdlc) 파일은 볼 수 없습니다.

1.15   IIS 작업자 프로세스가 SYSTEM으로 실행되는 경우 ASP.NET의 코드 검사가 작동하지 않습니다. 

IIS 작업자 프로세스가 SYSTEM으로 실행되는 경우 ASP.NET의 코드 검사 데이터를 수집할 수 없습니다.  IIS 작업자 프로세스 이름은 IIS 버전별로 다르므로 해당 시스템의 IIS 작업자 프로세스 이름을 MSDN에서 확인하십시오. 작업 관리자를 사용하여 작업자 프로세스를 실행하는 사용자를 확인할 수 있습니다.
참고: 코드 검사가 비활성화되어 있으면 단위 테스트가 제대로 실행됩니다.

이 문제를 해결하려면

SYSTEM으로 실행되지 않도록 IIS 작업자 프로세스를 변경합니다.

1.16   폼 인증이 활성화된 ASP.NET 응용 프로그램을 프로파일링하려고 하면 오류가 발생합니다.

폼 인증이 활성화된 ASP.NET 응용 프로그램을 프로파일링하려고 하면 웹 사이트 구성 오류가 발생하고 응용 프로그램이 실행되지 않습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

1.17   코드가 실행되고 있을 때 분산 시스템 디자이너 다이어그램에서 작업을 수행하면 Visual Studio가 응답하지 않습니다. 

예를 들어, 디버거가 실행되고 있을 때 시스템 디자이너에서 시스템 다이어그램에 응용 프로그램을 추가하면 Visual Studio가 응답하지 않습니다.

이 문제를 해결하려면

분산 시스템 디자이너 다이어그램에서 작업을 수행하는 코드를 실행하지 않습니다.

1.18   공유 dll을 추적 프로파일링하면 해당 dll을 사용하는 모든 프로세스가 프로파일링됩니다. 

공유 dll을 추적 프로파일링하려는 경우 해당 dll을 사용하는 모든 프로세스를 프로파일링하게 될 수 있습니다.

이 문제를 해결하려면

1) vsperfcmd -proccessoff:PID를 사용하여 프로파일링하지 않을 각 프로세스에서 프로파일링을 해제합니다.
2) HKCU/software/microsoft/visual studio/8.0/VSPERF/Monitor/Settings/ProcessProfile=Off를 설정하고 대상 프로세스를 시작한 다음 vsperfcmd -processon:PID를 사용하여 프로파일링할 모든 프로세스에서 프로파일링을 활성화합니다.
참고: 프로파일링을 마친 후 해당 공유 dll을 사용하고 있는 모든 프로세스를 종료하여 모니터를 종료하고 데이터를 보고서 파일로 플러시해야 합니다.

1.19   NGEN(Natively Generated)된 이미지를 추적 프로파일링하는 방법 

NGEN된 이미지를 계측하려고 하면 VSP1014 오류가 보고됩니다.
CLR에서는 계측되고 관리되는 바이너리 중에서 이미 NGEN된 바이너리를 로드하지 않습니다.

이 문제를 해결하려면

관리되는 바이너리 자체를 계측하고 NGEN된 이미지를 계측하지 않은 경우 다음 중 하나를 수행해야 합니다.

1) CLR에서 계측된 바이너리를 사용하도록 NGEN된 이미지를 삭제합니다.
-또는-
2) ngen.exe를 사용하여 바이너리를 다시 생성합니다.

1.20   MarkProfile 프로파일링 API를 사용하는 경우 프로파일러 모니터가 실행되지 않으면 충돌이 발생합니다.

vsperf.h에서 사용 가능한 MarkProfile, CommentMarkProfile 또는 CommentMarkAtProfile을 사용하는 경우 프로파일러 모니터가 실행되지 않으면 응용 프로그램 충돌이 발생합니다. 이러한 현상은 API 호출을 추가한 다음 프로파일러가 아니라 디버거에서 해당 호출을 시작하는 경우 두드러지게 나타납니다.

이 문제를 해결하려면

"vsperfcmd -start:sample -output:foo.vsp"를 사용하여 프로파일러 모니터를 시작합니다.

1.21   웹 프로젝트: GAC된 어셈블리에 정의된 형식을 클래스 다이어그램에 시각화할 수 없습니다. 

다음의 모든 조건에 해당하는 경우 클래스 다이어그램에 참조된 어셈블리의 형식을 표시할 수 없습니다.
1. 클래스 다이어그램이 웹 프로젝트 안에 있습니다.
2. 참조된 어셈블리가 GAC(전역 어셈블리 캐시)에 설치되어 있습니다.
3. 참조된 어셈블리가 프레임워크 디렉터리 루트("Microsoft.Net\Framework\<버전>\")에 설치되어 있지 않습니다.

이 문제를 해결하려면

웹 프로젝트가 아닌 곳에서 참조된 형식을 시각화합니다.

1.22   계측되고 관리되는 dll이 웹 사이트 프로젝트에 로드되지 않습니다. 

웹 사이트에 호스팅되며 계측되고 관리되는 사용자 컨트롤이 .NET에 대한 기본 보안 설정을 사용하여 로드되지 않습니다.

이 문제를 해결하려면

계측된 dll을 로드할 수 있으려면 로컬 웹 사이트에 대해 완전 신뢰를 활성화해야 합니다.
caspol.exe -ag 1.2 -url http://localhost FullTrust

1.23   응용 프로그램 검증 도구가 혼합 모드 C++ 프로젝트에 대해 활성화되지 않고 다음 대화 상자가 나타납니다.
"응용 프로그램 검증 도구가 선택된 디버그 모드에 지원되지 않습니다. 자세한 내용은 지원 설명서를 참조하십시오. 검증 도구 없이 디버깅을 계속하려면 확인을 클릭하십시오." 

디버그 메뉴에서 응용 프로그램 검증 도구를 선택할 수 있는 경우에도 검증 도구가 혼합 모드 응용 프로그램에 대해 활성화되지 않습니다.

이 문제를 해결하려면

응용 프로그램 검증 도구 없이 디버깅을 계속합니다.

1.24   프로파일러 드라이버가 Windows 2000에서 제대로 초기화되지 않습니다.

프로파일러 드라이버는 처음 사용될 때 자동으로 초기화되어야 합니다. 이러한 초기화가 원격 데스크톱 세션을 통해 Windows 2000 Server에서 발생하면 드라이버가 이후 세션에 사용할 수 있도록 초기화되지만 현재 세션에 사용할 수 있도록 초기화되지는 않습니다.  현재 세션에서 모니터를 시작하려고 하면 오류 VSP1398이 표시되고 모니터가 시작되지 않습니다.

이 문제를 해결하려면

다음 중 하나를 수행하십시오.

1) 컴퓨터를 다시 시작합니다.
-또는-

2) 원격 데스크톱을 사용하여 동일한 컴퓨터의 다른 세션에 연결합니다.

1.25   테스트 실행 창: "Controller users" 그룹에 속하지만 "Admin users"에 속하지 않는 사용자가 컨트롤러에 연결할 수 없습니다.  

사용자가 "Controller users" 그룹에 추가되고 "Controller admin" 그룹에 추가되지 않으면 컨트롤러 서비스가 다시 시작될 때까지 변경 사항이 적용되지 않으므로 사용자가 컨트롤러에 연결할 수 없습니다.

이 문제를 해결하려면

컨트롤러 서비스를 다시 시작합니다.

1.26   파일을 편집기에서 다시 로드할 때 인코딩 변경 내용이 나타나지 않을 수 있습니다. 

Visual Studio 2005에서는 파일을 다시 로드할 때 인코딩 변경 내용을 검색하지 않습니다. 현재 편집기 외부에서 파일의 인코딩을 변경했거나 소스 제어 작업을 수행하여 편집기에 열려 있는 파일의 인코딩을 변경한 경우 Visual Studio에서는 해당 파일을 자동으로 다시 로드합니다. 파일이 편집기에서 다시 로드된 다음 해당 내용이 올바르게 표시되지 않을 수 있습니다.

이 문제를 해결하려면

1. 변경 내용을 저장하지 않고 파일을 닫습니다.
   
2. 파일 메뉴에서 열기를 선택한 다음 파일을 선택합니다.
   
3. 파일 열기 대화 상자에서 열기 단추 옆에 있는 화살표를 클릭하고 연결 프로그램을 클릭합니다.
   
4. 연결 프로그램 대화 상자의 목록에서 파일을 열 편집기(예: 바이너리 편집기 또는 리소스 편집기)를 선택합니다. 특정 인코딩을 사용하여 파일을 열려면 XML 편집기(인코딩 사용)와 같이 인코딩을 지원하는 편집기를 선택합니다.
   
5. 확인을 클릭합니다.
   
6. 인코딩 대화 상자의 인코딩 드롭다운 목록에서 올바른 인코딩을 선택합니다.
   
7. 확인을 클릭합니다.
   

1.27   설치 프로젝트를 설치할 때 제품 복구가 발생합니다. 

Visual Studio 2005 다음에 Visual Studio 2003을 설치한 경우 두 버전의 Visual Studio 중 하나에서 설치 프로젝트를 빌드하면 제품 복구가 발생합니다. Visual Studio 2003을 설치한 사용자를 제외한 사용자에게만 제품 복구가 발생합니다.

이 문제를 해결하려면

제품 복구가 발생하면 완료되도록 둡니다. 복구에 성공하려면 Visual Studio 2003의 설치를 수행하지 않았으며 관리자 권한이 있는 사용자 계정에서 복구가 수행되어야 합니다.

1.28   Office 제품이 Visual Studio 2005 Tools for the Microsoft Office System 프로젝트를 설치한 후 실행되지 않습니다. 

등록이 필요 없는 COM 구성 요소가 포함된 Visual Studio 2005 Tools for the Microsoft Office System 추가 기능 프로젝트를 설치한 후 추가 기능의 대상인 Office 제품이 실행되지 않습니다.

이 문제를 해결하려면

Visual Studio 2005 Tools for the Microsoft Office System 추가 기능 프로젝트에는 등록이 필요 없는 COM이 지원되지 않습니다.

1.29   Visual Studio 2003에서 가져온 설치 및 배포 프로젝트가 빌드될 때 서명되지 않습니다. 

서명이 활성화된 Visual Studio 2003에서 가져온 설치 및 배포 프로젝트는 Visual Studio 2005에서 빌드될 때 서명되지 않습니다. 빌드할 때 오류 목록 창에 "파일 '' <filename> ''이(가) 서명되지 않았습니다. 배포 프로젝트에 사용되지 않는 서명 속성이 포함되어 있습니다. 자세한 내용은 도움말을 참조하십시오."라는 메시지가 나타납니다.

이 문제를 해결하려면

서명을 활성화하려면 설치 및 배포 프로젝트의 빌드 후 단계에서 빌드 출력에 대해 소프트웨어 개발 키트 도구 Signtool을 호출하면 됩니다. 이 방법에 대한 자세한 내용은 위에서 언급한 빌드 메시지와 관련된 도움말 항목을 참조하십시오. 오류 목록 창에서 메시지를 강조 표시한 다음 F1 키를 누르면 도움말에 액세스할 수 있습니다.

사용되지 않는 서명 프로젝트 속성을 제거하려면
1. 오류 목록 창에서 메시지를 두 번 클릭합니다.
2. 나타나는 대화 상자에서 ''예''를 클릭합니다. 이렇게 하면 사용되지 않는 서명 프로젝트 속성이 프로젝트 파일에서 제거됩니다.

1.30   Visual Studio 2005에서 사용할 수 있는 특정 부트스트래퍼 패키지가 32비트 플랫폼만 대상으로 합니다. 

Visual Studio 2005에서 사용할 수 있는 .NET Framework 2.0, SQL Server Express 2005, Microsoft Visual J# 재배포 가능 패키지, Windows Installer 2.0 및 Windows Installer 3.1에 대한 부트스트래퍼 패키지는 32비트 플랫폼만 대상으로 합니다. 이러한 패키지로 빌드된 부트스트래퍼가 64비트 플랫폼에서 실행되면 설치가 차단될 수 있습니다.

이 문제를 해결하려면

64비트 버전의 .NET Framework 2.0 및 SQL Server Express 2005 재배포 가능 패키지에 대한 부트스트래퍼 패키지는 Microsoft 다운로드 센터에서 제공될 예정입니다.

1.31   사용자 정의 형식을 설정으로 사용하면 설정 디자이너에서 예기치 않은 동작이 발생할 수 있습니다. 

사용자 정의 형식을 설정으로 사용하면 사용하는 프로젝트가 열려 있는 동안 UDT가 있는 어셈블리가 업데이트되는 경우 문제가 발생할 수 있습니다. 이 시나리오가 필요하면 UDT 어셈블리에서 증분 버전 의미 체계를 사용하도록 하여 문제를 방지할 수 있습니다.

이 문제를 해결하려면

설정으로 사용되고 있는 사용자 정의 형식이 클래스 라이브러리에 있으면 문제를 완화시키기 위해 라이브러리에 증분 버전을 적용합니다. 사용자 정의 형식이 EXE에 있으면 IDE를 닫고 다시 시작해야 UDT의 변경 내용이 적용됩니다.

1.32   사용자 정의 컨트롤 프로젝트 내의 "My"에 폼 속성이 없습니다. 

My.Forms¸¦ 사용자 정의 컨트롤 프로젝트에서 사용할 수 없습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

1.33   Sleep으로 중지된 경우 원격 디버깅을 통해 개체의 메서드를 호출할 수 없습니다. 

원격 컴퓨터에서 다음 코드를 실행하고 있는 상태에서 원격 디버깅을 통해 실행 중인 코드에 연결하고  실행이 Sleep()에 대한 호출 내에 있을 때 중단할 경우 c 변수의 멤버를 확인할 수 없습니다.

c = New c1     ''c1이 유효한 클래스라고 가정
While True
Threading.Thread.Sleep(1000)
End While

이 문제를 해결하려면

Sleep()을 나가면 개체를 정상적으로 확인할 수 있습니다.

1.34   Visual Studio 2005 Team Edition for Testers: 부하 테스트 오류 테이블에 "임계값 규칙을 적용하는 데 필요한 종속 카운터를 찾을 수 없습니다."가 포함됩니다. 

부하 테스트 결과 뷰어의 오류 테이블에 "임계값 규칙을 적용하는 데 필요한 종속 카운터를 찾을 수 없습니다."라는 메시지가 포함된 오류가 들어 있습니다. 부하 테스트에는 한 성능 카운터를 다른 성능 카운터와 비교하는 임계값 규칙이 포함되어 있습니다. 비교 성능 카운터에서 샘플링 간격 동안 인스턴스를 생성하지 않으면 이 오류가 발생합니다.

이 문제를 해결하려면

다른 성능 카운터 대신 상수와 비교하도록 관련 임계값 규칙을 변경합니다. 이러한 변경은 지정된 임계값 규칙을 실행하지 못하는 것보다 심각한 영향을 부하 테스트 결과에 주지 않으며 무시해도 안전합니다.

다음 절차를 수행하여 카운터를 변경하십시오.
1. 부하 테스트를 편집하고 카운터 집합/부하 테스트/카운터 범주/LoadTest:Request/카운터/평균 연결 대기 시간/임계값 규칙을 선택합니다.
2. 카운터 비교 규칙을 삭제합니다.
3. 마우스 오른쪽 단추를 클릭하여 상수 비교 규칙을 추가합니다.
규칙에서 초과하면 경고를 true로 설정하고 경고를 .01(10ms)로, 중요 임계값을 .02(20ms)로 설정합니다.

1.35   Visual Studio 2005 Team Edition for Testers: "개체의 인스턴스로 설정되지 않았습니다." 오류가 발생하면서 웹 테스트가 실행되지 않습니다. 

사용되지 않는 데이터 소스를 사용하여 코딩된 웹 테스트를 실행하면 "개체의 인스턴스로 설정되지 않았습니다." 오류가 발생하면서 실행되지 않습니다. 이러한 문제는 데이터 소스가 코딩된 웹 테스트에 정의되어 있지만 테스트의 항목에 바인딩되지 않았기 때문에 발생합니다.

이 문제를 해결하려면

코딩된 웹 테스트에서 사용되지 않는 데이터 소스를 제거하거나 DataBinding 특성을 테스트 클래스에 추가하여 데이터 소스의 필드를 테스트의 항목에 바인딩합니다.

1.36   Visual Studio 2005 Team Edition for Testers: SoapHttpClientProtocol 구현의 프록시 속성을 명시적으로 설정합니다. 

웹 서비스를 호출하는 단위 테스트가 포함된 부하 테스트를 실행하는 경우 단위 테스트 코드에서 System.Web.Services.Protocols.SoapHttpClientProtocol을 구현하는 웹 서비스 프록시 클래스의 프록시 속성을 명시적으로 설정해야 합니다. 이렇게 하면 프록시를 자동으로 감지해야 하는 경우 발생할 수 있는 성능 병목 상태가 방지됩니다.

예를 들어, 다음과 같은 웹 서비스 프록시 클래스가 있는 경우

[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.ComponentModel.DesignerCategoryAttribute("code")]
[System.Web.Services.WebServiceBindingAttribute(Name="InstantOrderSoap", Namespace="http://tempuri.org/")]
public partial class InstantOrder : System.Web.Services.Protocols.SoapHttpClientProtocol {

}

프록시 개체를 만든 다음 이 개체를 사용하기 전에 Proxy 속성을 명시적으로 설정합니다.

InstantOrder orderCheck = new InstantOrder();
orderCheck.Proxy = new WebProxy("myproxy", true);

1.37   ActiveX EXE 개체에 있는 variant 속성에 구조체를 전달할 수 없습니다. 

Windows 98에서는 ActiveX EXE 개체에 있는 variant 속성에 구조체를 전달할 수 없습니다. 문제는 Windows 9X 컴퓨터에 있습니다. 즉, 시스템 DLL rpcrt4.dll이 기본적으로 등록되지 않아 운영 체제에 등록 키 [HKEY_CLASSES_ROOT\CLSID\{B5866878-BD99-11D0-B04B-00C04FD91550}]이 없습니다. 이러한 등록 누락으로 인해 호출이 실패합니다.

이 문제를 해결하려면

C:\Windows\System으로 이동하여 RegSvr32.exe rpcrt4.dll을 직접 호출합니다.

1.38   순환 제약 조건이 있는 형식 매개 변수에 새 개체를 추가하면 VB 컴파일러가 지연되고 메모리 할당이 증가합니다. 

콘솔 응용 프로그램에서 아래의 코드를 붙여 넣으면 응용 프로그램이 지연됩니다.

Class C1(Of U As U)    ''여기에 있는 순환 제약 조건으로 인해 나중에 문제가 발생함
End Class

Partial Class C1(Of U)
Dim x As New U        ''문제 - 이로 인해 무한 루프가 발생하고 더 이상 사용할 수 있는 메모리가 없을 때까지 메모리 사용이 계속 증가함

End Class

이 문제를 해결하려면

순환 제약 조건을 제거합니다.

1.39   ClickOnce를 사용하여 응용 프로그램을 시작하면 StartupNextInstanceEvent 처리기에 대한 매개 변수가 명령줄 인수를 포함하지 않습니다. 

ClickOnce를 사용하여 응용 프로그램을 시작하면 StartupNextInstanceEvent 처리기에 대한 매개 변수가 응용 프로그램의 두 번째 인스턴스에 대한 명령줄 인수를 포함하지 않습니다. 명령줄 인수를 가져오려면 My.Application.Deployment.ActivationUri 속성을 사용해야 합니다.

이 문제를 해결하려면

다음과 같이 ASP 런타임 클래스를 사용하여 명령줄 인수를 가져옵니다.

Imports System.Web

Dim commandLineArgs as NameVal‎ueCollection = _
HttpUtility.ParseQuery(My.Application.Deployment.ActivationUri)

1.40   VB 컴파일러가 InternalsVisibleTo 특성을 지원하지 않습니다. 

<어셈블리: InternalsVisibleTo("Foo.Dll, PublicKeyToken=a29c01bbd4e39ac5")>

이 특성은 다른 어셈블리에 Friend 형식을 노출합니다. VB 컴파일러에서는 이 특성을 지원하지 않습니다.

전용 형식 테스트를 위해 이 특성을 사용하는 일부 단위 테스트 기술이 예상대로 작동하지 않습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

1.41   vsperfcmd.exe의 일부 설명서가 없습니다. 

일반적인 사용자 시나리오를 설명하는 vsperfcmd의 설명서가 없습니다.

vsperfcmd.exe에서 사용할 수 있는 일반적인 명령의 예는 다음과 같습니다.
vsperfcmd -start:sample -output:foo.vsp
vsperfcmd -start:trace -output:foo.vsp -counter:g,1,0,InstructionsRetired
vsperfcmd -launch:foo.exe -args:"input arguments" -gc:lifetime
vsperfcmd -attach:foo.exe -pf:1

1.42   VB 웹 컨트롤 라이브러리 프로젝트에서 My.Log를 사용할 수 없습니다. 

VB 웹 컨트롤 라이브러리 프로젝트에서는 My.Log를 사용할 수 없습니다. My가 프로젝트별로 존재하기 때문에 웹 사이트 프로젝트에 있는 WebUserControls의 경우 My.Log를 사용할 수 있지만 웹 사이트에서 사용되는 웹 컨트롤 라이브러리 프로젝트에 있는 클래스의 경우에는 My.Log를 사용할 수 없습니다.

이 문제를 해결하려면

My.Log 메서드 대신 Trace.Write를 사용합니다.

1.43   사용자에게 파일 I/O 사용 권한이 없으면 My.Application.Log.WriteEntry에서 예외를 throw할 수 있습니다. 

1) 다음 코드를 사용하여 새 콘솔 응용 프로그램을 만듭니다.

    My.Application.Log.DefaultFileLogWriter.CustomLocation = "D:\temp"
    My.Application.Log.WriteEntry("Foo")

2) 응용 프로그램을 실행합니다.

결과:
로그 파일이 D:\temp에 만들어지며, 없는 경우 D:\Documents and Settings\<username>\Application Data\Microsoft\WindowsApplication1\1.0.0.0 디렉터리도 만들어집니다. 사용자에게 이러한 작업을 수행할 수 있는 권한이 없으면 예외가 throw됩니다. ASP.NET 프로세스에는 기본적으로 어떤 Application Data 디렉터리에 대한 쓰기 권한도 없으므로 웹 응용 프로그램에서 클래스 라이브러리를 사용할 때 예외가 throw될 가능성이 높습니다.

이 문제를 해결하려면

1) app.config를 통해 기본 FileLogTraceListener를 제거하고 다른 TraceListener를 사용하도록 My.Application.Log를 다시 구성합니다.
2) 처리되지 않은 예외 이벤트를 수신 대기하고 이 이벤트가 발생하면 작업을 계속 수행합니다.
3) 기록되는 모든 호출 또는 최소한 처음으로 실행할 가능성이 있는 기록되는 호출을 try/catch합니다.

1.44   32비트 COM 구성 요소에 대한 참조는 64비트 플랫폼에서 실행되는 VB 및 C# 응용 프로그램에서 작동하지 않을 수 있습니다.  

대부분의 기존 COM 구성 요소는 32비트 플랫폼에서만 사용할 수 있으며 64비트 플랫폼의 64비트 프로세스에서는 실행되지 않습니다. 하지만 64비트 플랫폼의 32비트 프로세스에서는 올바르게 실행됩니다. 이러한 32비트 COM 구성 요소를 참조하는 VB 및 C# 응용 프로그램은 기본적으로 64비트 프로세스로 시작되므로 64비트 플랫폼에서 실행되지 않습니다.

하나 이상의 COM 참조를 포함하는 프로젝트가 다음과 같을 때 이러한 문제가 발생합니다.
1. Visual Studio 2005로 마이그레이션되어 64비트 플랫폼에서 실행됩니다.

-또는-
2. 64비트 플랫폼에서 Visual Studio 2005를 사용하여 만들어졌습니다.

Visual Studio 2005에서 VB 및 C# 컴파일러는 플랫폼 대상 속성을 사용하여 .exe 또는 .dll을 32비트 CPU 아키텍처 모드에서 실행할지 64비트 모드에서 실행할지 결정합니다. Visual Studio 2005에서 이 속성의 기본 설정은 ''AnyCPU''로 되어 있는데 이 설정은 호스트 플랫폼에 따라 응용 프로그램이 32비트 모드와 64비트 모드 모두에서 실행될 수 있음을 나타냅니다. 이러한 상황에서 응용 프로그램을 디버깅하거나 실행하려고 하면 "클래스를 인스턴스화할 수 없습니다..."와 같은 메시지가 발생할 수 있습니다.

이 문제를 해결하려면

COM 구성 요소에 대한 참조가 있는 VB 또는 C# 프로젝트에 대해 플랫폼 대상 속성을 ''X86''으로 설정합니다.

C# 프로젝트의 경우:
1.    솔루션 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 ''속성''을 엽니다.
2.    빌드 탭을 선택합니다.
3.    플랫폼 대상 속성을 ''X86''으로 설정합니다.

VB 프로젝트의 경우:
1.    솔루션 탐색기에서 프로젝트를 마우스 오른쪽 단추로 클릭하고 ''속성''을 엽니다.
2.    컴파일 탭을 선택합니다.
3.    고급 컴파일 옵션... 단추를 누릅니다.
4.    대상 CPU 속성을 ''X86''으로 설정합니다.

Express Edition의 경우:
VB 및 C# Express 제품에서는 개발 환경 내에서 대상 속성을 노출하지 않습니다. 텍스트 편집기 또는 XML 편집기를 사용하여 프로젝트 파일을 신중하게 수정해야 합니다.
1.    프로젝트 및/또는 솔루션을 닫습니다.
2.    파일 메뉴에서 파일 열기를 선택합니다.
3.    프로젝트 디렉터리로 이동하여 프로젝트 파일을 강조 표시합니다.
4.    열기 단추를 누르면 XML 편집기에 프로젝트 파일이 열립니다.
5.    첫 번째 <PropertyGroup> 섹션을 찾아 다음 줄을 추가합니다.
<PlatformTarget>x86</PlatformTarget>
1.    프로젝트 파일을 저장합니다.
2.    파일 메뉴의 프로젝트/솔루션 열기를 사용하여 프로젝트 및/또는 솔루션을 다시 엽니다.
3.    개발/디버깅/테스팅을 계속합니다.

응용 프로그램의 대상이 64비트 플랫폼인 경우에는 응용 프로그램에 추가된 COM 컨트롤의 64비트 버전이 개발 및 배포 컴퓨터에 있도록 할 수 있습니다.

1.45   Windows 로밍 프로필을 사용하면 시작할 때마다 처음 시작 메시지가 나타날 수 있습니다. 

Visual Studio 제품군의 제품을 Windows 로밍 프로필과 함께 사용하면 세션을 시작할 때마다 "Visual Studio 2005에서 처음 사용하는 데 필요한 환경을 구성하고 있습니다. 몇 분 정도 걸릴 수 있습니다."라는 처음 시작 메시지가 나타날 수 있습니다. 이로 인해 시작 성능이 필요 이상으로 저하될 수 있습니다.

이 문제를 해결하려면

도구 > 옵션...을 클릭합니다. "설정 가져오기 및 내보내기"를 선택하고 "이 파일에 사용자 설정 자동 저장:" 아래의 경로를 "내 문서" 디렉터리 아래에 있지 않은 경로로 변경합니다.

1.46   Visual Studio 2005가 시작되기 전에 DTE.CommandBars에 액세스하는 추가 기능을 설치하면 추가 기능 로드 오류가 발생합니다. 

Visual Studio 2005를 처음 설치한 후 OnConnection에서 DTE.CommandBars를 가져오려는 추가 기능이 설치된 경우 Visual Studio 2005를 처음 시작하면 다음 메시지가 표시됩니다.

    <추가 기능 이름> 추가 기능을 로드하지 못했거나 예외가 발생했습니다.
    이 추가 기능을 제거하시겠습니까?

이 문제를 해결하려면

Visual Studio 2005를 설치하는 경우 설치한 후 추가 기능을 설치하기 *전에* Visual Studio를 시작하고 다시 종료합니다. 
이 추가 기능이 이미 설치되어 위의 메시지가 표시되면 "아니요"를 클릭하고 Visual Studio를 닫습니다. 명령 프롬프트에서 <VSInstallDir>\Common7\IDE로 이동하고 다음 명령을 실행합니다.
    devenv /resetaddin *

1.47   클래스 라이브러리를 마지막으로 빌드할 때 Visual Basic 또는 Visual J# 클래스 라이브러리의 웹 서비스 참조가 리버스 엔지니어링되지 않을 수 있습니다. 

이 시나리오에서 Visual Studio 솔루션에는 웹 서비스에 대한 웹 참조가 포함된 Visual Basic 또는 Visual J# 클래스 라이브러리가 들어 있습니다. 솔루션에는 클래스 라이브러리에 대한 참조가 포함된 ASP.NET 웹 사이트도 들어 있습니다. 이러한 항목이 솔루션에 추가된 후 특정 구성 파일 항목이 클래스 라이브러리의 App.config 파일에서 웹 사이트의 Web.config 파일로 복사되어야 합니다. 클래스 라이브러리가 구성 파일 항목을 복사했지만 이들 항목이 리버스 엔지니어링되도록 응용 프로그램 다이어그램을 추가하지 않은 상태에서 빌드된 경우 ASP.NET 웹 사이트만 다이어그램에서 리버스 엔지니어링될 수 있습니다. 따라서 웹 서비스 참조가 ASP.NET 응용 프로그램에서 웹 서비스 소비자 끝점으로 리버스 엔지니어링되지 않을 수 있으며 참조된 웹 서비스에 대한 연결이 리버스 엔지니어링되지 않을 수 있습니다. 다이어그램에 없는 웹 서비스에 대한 웹 참조의 경우 참조된 웹 서비스의 외부 웹 서비스가 리버스 엔지니어링되지 않을 수 있습니다.

이 문제를 해결하려면

1. 응용 프로그램 다이어그램이 추가된 후 클래스 라이브러리에서 웹 참조를 마우스 오른쪽 단추로 클릭하고 웹 참조 업데이트를 선택합니다.
2. 클래스 라이브러리를 다시 빌드합니다.

1.48   테이블 위치를 변경하면 연결이 되지 않을 수 있습니다. 

런타임에 테이블의 위치를 다른 데이터베이스로 변경하는 경우 새 데이터베이스에 원래 보고서에 있는 테이블과 이름이 같은 테이블이 포함되어야 합니다. 테이블 이름이 일치하지 않으면 연결이 되지 않습니다.

이 문제를 해결하려면

새 데이터베이스에 원래 보고서에 있는 테이블과 이름이 같은 테이블이 포함되도록 합니다.

1.49   Null 문자열을 사용하여 뷰어 선택 수식을 설정하면 안 됩니다. 

보고서에 있는 모든 레코드를 표시하도록 뷰어 선택 수식을 설정하려면 null 문자열 대신 빈 문자열을 사용합니다. null 문자열로는 원래 보고서 선택 수식을 재정의할 수 없습니다.

이 문제를 해결하려면

빈 문자열은 "" 또는 String.Empty로 표시됩니다. null 문자열은 C#에서 null로, Visual Basic에서 Nothing으로 표시됩니다.

1.50   Shift-JIS로 인코딩된 프로젝트를 마이그레이션하면 문자가 잘못될 수 있습니다. 

Shift-JIS로 인코딩된 일본어 문자는 Visual Studio 2002 또는 Visual Studio 2003에서 Visual Studio 2005로 마이그레이션된 ASP.NET 웹 응용 프로그램에서 제대로 표시되지 않습니다.

이 문제를 해결하려면

마이그레이션하기 전에 모든 ASP 페이지를 UTF-8로 변환합니다.

1.51   Crystal Reports 9 또는 Crystal Reports 10에서 프로젝트를 가져오면 네임스페이스 참조가 손실됩니다. 

CrystalDecisions.ReportSource, CrystalDecisions.Shared 및 CrystalDecisions.Windows.Forms 어셈블리에 대한 참조는 Crystal Reports 9 또는 Crystal Reports 10의 Windows 프로젝트가 Crystal Reports for Visual Studio 2005로 마이그레이션될 때 손실됩니다.

이 문제를 해결하려면

마이그레이션 후 응용 프로그램을 컴파일하기 전에 참조를 직접 추가합니다.

1.52   Windows 및 ASP.NET 웹 프로젝트가 동일한 클래스 라이브러리를 참조하면 해당 클래스 라이브러리의 웹 서비스 참조가 리버스 엔지니어링되지 않을 수 있습니다. 

이 시나리오에서 Visual Studio 솔루션에는 Windows 및 ASP.NET 응용 프로그램이 구현되어 있는 응용 프로그램 다이어그램이 들어 있습니다. 솔루션에는 웹 서비스에 대한 웹 참조가 포함된 클래스 라이브러리도 들어 있습니다. Windows 및 ASP.NET 웹 프로젝트는 이 클래스 라이브러리를 참조합니다. 클래스 라이브러리가 빌드되고 필요한 항목이 클래스 라이브러리의 App.config 파일에서 두 프로젝트의 구성 파일로 복사된 후 웹 참조가 Windows 또는 ASP.NET 응용 프로그램에서 웹 서비스 소비자 끝점으로 리버스 엔지니어링되지 않을 수 있습니다. 참조된 웹 서비스에 대한 연결도 리버스 엔지니어링되지 않을 수 있습니다. 다이어그램에 없는 웹 서비스에 대한 웹 참조의 경우 참조된 웹 서비스의 외부 웹 서비스가 리버스 엔지니어링되지 않을 수 있습니다.

이 문제를 해결하려면

1. 응용 프로그램 다이어그램을 닫습니다.
2. Windows 및 ASP.NET 프로젝트에서 공유 클래스 라이브러리에 대한 참조를 제거합니다.
3. ASP.NET 프로젝트에 클래스 라이브러리 참조를 추가합니다.
4. 응용 프로그램 다이어그램을 엽니다.
5. Windows 프로젝트에 클래스 라이브러리 참조를 추가합니다.

1.53   FTP 웹의 서버 탐색기에서 데이터 파일을 확장하면 IDE가 충돌할 수 있습니다. 

FTP 웹 사이트를 열고 App_Data 디렉터리에 데이터 파일(MDB 또는 MDF)을 추가한 다음 서버 탐색기 창을 열고 데이터 연결 노드 아래의 데이터 파일에 대한 연결을
확장하면 IDE가 충돌하거나 지연될 수 있으며 저장하지 않은 데이터가 모두 손실될 수 있습니다.

이 문제를 해결하려면

파일 시스템이나 IIS 웹 사이트를 사용하여 로컬 파일 위치에서 웹 사이트를 개발하고 웹 사이트 복사 명령을 사용하여 파일을 FTP 위치에서 또는 FTP 위치로 전송합니다.

1.54   Firefox에서 인쇄하거나 내보내면 예외가 throw될 수 있습니다. 

CrystalReportViewer 컨트롤에서 보고서를 내보내거나 인쇄하면 예외가 throw될 수 있습니다. CrystalReportViewer 컨트롤과 Microsoft 웹 컨트롤이 포함된 웹 페이지를 Firefox 웹 브라우저에서 보면 이 문제가 발생합니다.

이 문제를 해결하려면

Firefox에서 보고서를 인쇄하거나 내보낼 수 있도록 ASP 페이지에서 EnableEventValidation을 False로 설정합니다.

1.55   응용 프로그램 검증 도구가 혼합 모드 C++ 프로젝트에 대해 활성화되지 않고 다음 메시지가 나타납니다.
"응용 프로그램 검증 도구가 선택된 디버그 모드에 지원되지 않습니다. 자세한 내용은 지원 설명서를 참조하십시오. 검증 도구 없이 디버깅을 계속하려면 확인을 클릭하십시오." 

디버그 메뉴에서 응용 프로그램 검증 도구를 선택할 수 있는 경우에도 검증 도구가 혼합 모드 응용 프로그램에 대해 활성화되지 않습니다. 응용 프로그램 검증 도구가 활성화되지 않음을 나타내는 대화 상자가 표시되며 이 대화 상자에서 응용 프로그램 검증 도구 없이 디버깅을 계속하도록 선택할 수 있습니다.

이 문제를 해결하려면

응용 프로그램 검증 도구 없이 디버깅을 계속합니다.

1.56   Visual Studio 2005 Team Edition for Testers: 부하 테스트 결과가 적절한 구성에도 불구하고 결과 데이터베이스에 저장되지 않습니다. 

로컬 실행의 부하 테스트 결과가 적절한 부하 테스트 구성에도 불구하고 결과 데이터베이스에 저장되지 않습니다. 이 경우 다음 메시지가 표시됩니다.
"부하 테스트 결과 데이터베이스를 열 수 없습니다. 테스트 컨트롤러(또는 로컬 컴퓨터)에 대해 연결 문자열에서 지정된 부하 테스트 결과 데이터베이스가 부하 테스트 스키마를 포함하는 데이터베이스를 지정하고 있는지, 그리고 이 데이터베이스를 현재 사용할 수 있는지 확인하십시오."
로컬 부하 테스트 결과 데이터베이스는 첫 번째 로컬 부하 테스트 실행을 초기화ÇÏ´Â µ¿¾È 만들어집니다. 이 오류는 첫 번째 부하 테스트 실행을 시작하는 사용자에게 데이터베이스를 만들 수 있는 충분한 권한이 없으면 발생합니다.

이 문제를 해결하려면

관리자가 첫 번째 부하 테스트 실행을 시작하여 부하 테스트 결과 데이터베이스가 만들어지도록 해야 합니다.

1.57   Visual Studio 2005 Team Edition for Testers: SQL Express에 저장된 부하 테스트 결과를 원격 컴퓨터에서 액세스하지 못할 수 있습니다. 

SQL Express 구성과 Windows 방화벽 때문에 SQL Express에 저장된 부하 테스트 결과에 대한 원격 액세스가 차단될 수 있습니다. SQL Express의 기본 설치에서는 데이터베이스에 대한 원격 액세스를 비활성화합니다. 부하 컨트롤러 설치에서는 SQL Express에 대한 원격 액세스를 허용하도록 SQL Express 구성과 Windows 방화벽 구성을 자동으로 설정하지만, SQL Express도 설치하는 경우 이렇게 구성을 변경합니다. Visual Studio 설치에서도 SQL Express를 설치할 수 있지만 원격 액세스를 허용하도록 SQL Express 및 Windows 방화벽 구성을 자동으로 변경하지 않습니다.

부하 테스트 결과 뷰어가 SQL Express의 부하 테스트 결과에 원격으로 액세스할 수 없는 경우 다음 메시지가 표시됩니다.

"결과 리포지토리를 읽을 수 없습니다. 부하 테스트 결과 리포지토리에 액세스할 수 없습니다. 서버에 연결하는 동안 오류가 발생했습니다. SQL Server 2005에 연결하는 경우 이 오류는 기본 설정에 따라 SQL Server에서 원격 연결을 허용하지 않기 때문에 발생할 수 있습니다."

이 문제를 해결하려면

원격 액세스를 허용하도록 SQL Express와 Windows 방화벽을 직접 구성합니다. 다음 단계를 수행하여 SQL Express에 대한 원격 액세스를 활성화하십시오.

1. 시작, 모든 프로그램, Microsoft SQL Server 2005, 구성 도구, SQL Server 구성 관리자를 차례로 클릭하여 SQL Server 구성 관리자를 엽니다.
2. SQL Server 구성 관리자의 왼쪽 창에서 SQL Server 2005 네트워크 구성 노드를 확장하고 SQLEXPRESS에 대한 프로토콜을 선택합니다.
3. 오른쪽 창에서 명명된 파이프를 마우스 오른쪽 단추로 클릭하고 사용을 선택합니다.
4. TCIP/IP를 마우스 오른쪽 단추로 클릭하고 사용을 선택합니다.
5. 왼쪽 창에서 SQL Server 2005 서비스를 선택합니다.
6. 오른쪽 창에서 SQL Server Browser를 마우스 오른쪽 단추로 클릭하고 속성을 선택합니다.
7. 속성 대화 상자에서 서비스 탭을 클릭합니다.
8. 서비스 페이지에서 시작 모드 속성을 자동으로 설정하고 확인을 클릭합니다.
9. SQL Server Browser를 마우스 오른쪽 단추로 클릭하고 시작을 선택합니다.
10. SQL Server (SQLEXPRESS)를 마우스 오른쪽 단추로 클릭하고 다시 시작을 선택합니다.

다음 단계를 수행하여 Windows 방화벽을 구성하십시오.

1. Windows 방화벽 대화 상자를 열고 예외 탭을 클릭합니다.
2. 프로그램 추가와 찾아보기를 클릭하여 sqlbrowser.exe를 찾고 확인을 클릭합니다.
3. 프로그램 추가와 찾아보기를 클릭하여 sqlservr.exe를 찾고 확인을 클릭합니다.
4. 포트 추가를 클릭하고 이름에 "SQL Service"를 입력한 다음 포트 번호에 1433을 입력하고 TCP 라디오 단추를 선택합니다.
5. Windows 방화벽 대화 상자에서 확인을 클릭합니다.

1.58   Interop의 Long(VT_I8) 지원이 WinXP로 제한됩니다. 

Long(VT_I8)을 전달하는 Win2K 또는 Win9x에 대한 런타임 바인딩 호출은 실패합니다. WinXP는 OLE 자동화를 통해 VT_I8이 지원되는 유일한 플랫폼입니다.

이 문제를 해결하려면

long 대신 integer를 사용합니다.

1.59   EnvDTE80.WindowKinds.vsWindowKindImmediate 상수가 올바르지 않습니다. 

vsWindowKindImmediate 상수가 직접 실행 창에 대한 올바른 GUID를 반환하지 않습니다.

이 문제를 해결하려면

vsWindowKindImmediate 상수 대신 GUID {ECB7191A-597B-41F5-9843-03A4CF275DDE}를 사용합니다.
또는 다음을 실행하여 올바른 직접 실행 창 GUID를 가져옵니다.
    DTE.Windows.Item("Immediate Window").ObjectKind

1.60   공유 추가 기능 마법사 설치 프로젝트가 Microsoft Office만 있는 컴퓨터에서 작동하지 않습니다. 

Office 추가 기능이 실행되려면 Extensibility.dll이 필요합니다. Extensibility.dll은 공유 추가 기능의 설치 프로젝트에 자동으로 포함되지 않습니다.

이 문제를 해결하려면

솔루션 탐색기에서 추가 기능 설치 프로젝트를 마우스 오른쪽 단추로 클릭하고 추가 | 어셈블리를 선택합니다. .NET 탭에서 확장성을 선택하고 확인을 누릅니다. 어셈블리가 추가되면 솔루션 탐색기에서 해당 어셈블리를 선택하고 "Register" 속성이 "vsdraDoNotRegister"로 설정되었는지 확인합니다.

1.61   글꼴 및 색 옵션이 다시 설정 후 바로 반영되지 않습니다. 

도구 > 설정 가져오기 및 내보내기...를 클릭한 다음 "모두 다시 설정"을 선택하여 환경 설정을 다시 설정할 수 있습니다. 명령 창 내에서 "Tools.ImportAndExportSettings /reset" 명령을 실행하여 환경 설정을 다시 설정할 수도 있습니다. 어떤 방법을 사용하든 글꼴 및 색 옵션은 Visual Studio를 다시 시작해야 반영됩니다.

이 문제를 해결하려면

다시 설정 작업을 수행한 다음 Visual Studio를 다시 시작합니다.

1.62   응용 프로그램 검증 도구가 DLL 기반 프로젝트, ATL 웹 서비스 프로젝트 및 VC 스마트 장치 프로젝트에 지원되지 않습니다. 

응용 프로그램 검증 도구는 다음 시나리오에서 지원되지 않습니다.
1. DLL 프로젝트에서 응용 프로그램 검증 도구를 사용하여 시작를 사용하고 솔루션의 일부가 아닌 실행 파일에서 해당 프로젝트를 로드합니다.
2. 프로젝트 속성 | 디버깅에서 명령을 현재 로드된 프로젝트가 아닌 프로젝트로 변경합니다($TargetPath). 이것은 원격 디버깅에도 적용됩니다.
3. ATL 웹 서비스 프로젝트가 다른 프로세스에서 실행되므로 응용 프로그램 검증 도구가 ATL 웹 서비스 프로젝트에 지원되지 않습니다.
4. VC 스마트 장치 프로젝트가 다른 아키텍처에서 실행되므로 응용 프로그램 검증 도구가 VC 스마트 장치 프로젝트에 지원되지 않습니다.
응용 프로그램 검증 도구는 IDE에 로드된 exe 프로젝트에만 사용할 수 있습니다.

이 문제를 해결하려면

위의 시나리오 1 및 2의 경우 IDE에서 대상 실행 파일의 프로젝트를 로드한 다음 응용 프로그램 검증 도구를 사용합니다. 위의 모든 경우에 응용 프로그램 검증 도구를 사용하면 일반 디버그 세션(디버그 | 시작)과 동일하게 작동합니다.

1.63   Windows 및 ASP.NET 웹 프로젝트가 동일한 클래스 라이브러리를 참조하면 해당 클래스 라이브러리의 웹 서비스 참조가 리버스 엔지니어링되지 않을 수 있습니다. 

이 시나리오에서 Visual Studio 솔루션에는 Windows 및 ASP.NET 응용 프로그램이 구현되어 있는 응용 프로그램 다이어그램이 들어 있습니다. 솔루션에는 웹 서비스에 대한 웹 참조가 포함된 클래스 라이브러리도 들어 있습니다. Windows 및 ASP.NET 웹 프로젝트는 이 클래스 라이브러리를 참조합니다. 클래스 라이브러리가 빌드되고 필요한 항목이 클래스 라이브러리의 App.config 파일에서 두 프로젝트의 구성 파일로 복사된 후 웹 참조가 Windows 또는 ASP.NET 응용 프로그램에서 웹 서비스 소비자 끝점으로 리버스 엔지니어링되지 않을 수 있습니다. 참조된 웹 서비스에 대한 연결도 리버스 엔지니어링되지 않을 수 있습니다. 다이어그램에 없는 웹 서비스에 대한 웹 참조의 경우 참조된 웹 서비스의 외부 웹 서비스가 리버스 엔지니어링되지 않을 수 있습니다.

이 문제를 해결하려면

1. 응용 프로그램 다이어그램을 닫습니다.
2. Windows 및 ASP.NET 프로젝트에서 공유 클래스 라이브러리에 대한 참조를 제거합니다.
3. ASP.NET 프로젝트에 클래스 라이브러리 참조를 추가합니다.
4. 응용 프로그램 다이어그램을 엽니다.
5. Windows 프로젝트에 클래스 라이브러리 참조를 추가합니다.

1.64   Visual Studio 2005 Team Edition for Testers: "개체의 인스턴스로 설정되지 않았습니다." 오류가 발생하면서 웹 테스트가 실행되지 않습니다. 

사용되지 않는 데이터 소스를 사용하여 코딩된 웹 테스트를 실행하면 "개체의 인스턴스로 설정되지 않았습니다." 오류가 발생하면서 실행되지 않습니다. 이러한 문제는 데이터 소스가 코딩된 웹 테스트에 정의되어 있지만 테스트의 항목에 바인딩되지 않았기 때문에 발생합니다.

이 문제를 해결하려면

코딩된 웹 테스트에서 사용되지 않는 데이터 소스를 제거하거나 DataBinding 특성을 테스트 클래스에 추가하여 데이터 소스의 필드를 테스트의 항목에 바인딩합니다.

1.65   데이터 소스 창에서 필드를 복사하고 붙여 넣은 후 컨트롤의 DataBindings 속성이 올바르지 않습니다. 

데이터베이스 데이터 소스에서 필드를 끌어서 놓는 대신 복사하고 붙여 넣는 방법으로 Windows Forms 디자이너에 컨트롤을 생성하는 경우 데이터 바인딩 속성이 테이블 내의 필드가 아니라 테이블로 설정됩니다. 개체 및 웹 데이터 소스는 영향을 받지 않습니다.

이 문제를 해결하려면

Windows Forms 디자이너에 추가된 각 컨트롤의 경우 속성을 편집하고 (DataBindings) 속성을 올바른 데이터 소스로 변경합니다.

1.66   SQL Server 2005와 동일한 컴퓨터에 VS를 설치하면 VS에서 Business Intelligence 프로필을 사용할 수 있습니다. 

SQL Server 2005가 설치되어 있는 컴퓨터에 Visual Studio 2005를 설치하면 처음 VS를 시작할 때 프로필을 선택하라는 메시지가 표시되지 않고 VS 프로필이 Business Intelligence 개발용으로 설정됩니다. 이 문제는 SQL Server 2005에서 Business Intelligence 개발을 지원하는 Visual Studio 버전(Business Intelligence Development Studio)을 설치하고 VS 프로필을 이에 맞게 설정하기 때문에 발생합니다.

이 문제를 해결하려면

VS 프로필은 VS 도구 메뉴에서 "설정 가져오기 및 내보내기..."를 선택하면 시작되는 설정 가져오기 및 내보내기 마법사를 사용하여 언제든지 변경할 수 있습니다.

마법사에서 "모두 다시 설정"을 선택하고 다음 >을 클릭한 후 "예, 현재 설정을 저장합니다."를 선택합니다. 그런 후 다음 >을 클릭하고 원하는 프로필(예: 일반 개발 설정)을 선택한 다음 마침을 클릭합니다.

새 설정을 모두 적용하려면 VS를 다시 시작해야 할 수도 있습니다.

1.67   컴퓨터를 업데이트하지 않으면 공유 추가 기능이 컴퓨터에 로드되지 않을 수 있습니다. 

추가 기능이 실행되는 컴퓨터를 업데이트하지 않으면 공유 추가 기능이 Word 또는 Excel에 로드되지 않을 수 있습니다.

이 문제를 해결하려면

자세한 내용은 http://go.microsoft.com/fwlink/?LinkId=52419에 있는 기술 자료 문서를 참조하십시오.

1.68   C# Express SKU가 제거되면 VS 콘텐츠 설치 관리자가 실패합니다. 

C# Express SKU를 설치하고 기본 SKU 중 하나를 설치한 다음 C# Express SKU를 제거하면 VS 콘텐츠 설치 관리자가 시작 시 실패합니다.

이 문제를 해결하려면

제어판 | 프로그램 추가/제거에서 Visual Studio의 복구를 실행합니다.

1.69   영어가 아닌 Windows 운영 체제에 .addin 파일을 설치하면 문제를 발생할 수 있습니다. 

컴퓨터에 설치되어 있는 운영 체제의 언어가 영어가 아닌 Windows 운영 체제이고 "Documents and Settings\All Users\Application Data\Microsoft\MSEnvShared\Addins" 폴더의 일부가 지역화되어 있는 경우 추가 기능에서 이 경로를 인식하지 못합니다.

이 문제를 해결하려면

1. Visual Studio 2005에서 도구 | 옵션 | 추가 기능/매크로 보안으로 이동합니다.
2. 추가 기능 파일 경로에서 .addin 파일의 전체 경로를 추가합니다.

또는 .addin 파일을 [시스템 드라이브]:\Documents and Settings\All Users\Application Data\Microsoft\MSEnvShared\Addins에 설치합니다.

1.70   [서명 없는 UTF-8 인코딩 자동 검색] 옵션이 꺼져 있는 Visual Studio 편집기에서 소스 파일에 가비지 값이 보이는 경우가 있을 수 있습니다.

Visual Studio 에서, [도구]->[옵션]->[텍스트 편집기]->[일반]의 [서명 없는 UTF-8 인코딩 자동 검색] 옵션이 기본으로 꺼져 있습니다.  [서명 없는 UTF-8 인코딩 자동 검색] 옵션이 꺼져있는 컴퓨터에서는 서명 없는 UTF-8 형식의 파일을  기본 코드 페이지로 열는 경우가 있기 때문에, 편집기에서 가비지가 보일 수 있습니다.

이 문제를 해결하려면

1. [도구]->[옵션]->[텍스트 편집기]->[일반]을 선택한 후 [서명 없는 UTF-8 인코딩 자동 검색] 옵션을 켜십시오. 이 후에도 이 문제가 발생하지 않습니다. 참고. [서명 없는 UTF-8 인코딩 자동 검색] 옵션을 켤 경우, UTF-8 영역과 한국어 (ks_c_5601-1987) 영역에 중복되어 있는 문자들만 파일에 포함되어 있을 경우 서명 없는 UTF-8 파일을 한국어 파일로 잘못 인식하여 가비지가 발생할 수 있습니다.
2. 혹은 해당 파일을 [다른 이름으로 저장]-> [인코딩하여 저장]을 선택하여 서명 있는 UTF-8 파일 형식으로 바꿀 수 있습니다.

2. .NET Framework

2.1  제목에 DBCS(더블바이트 문자 집합) 문자가 포함된 Microsoft Word 형식의 수동 테스트를 실행하는 동안 및 실행한 후에 해당 테스트가 올바르게 표시되지 않습니다. 

수동 테스트를 실행하는 동안 수동 테스트 [실행 중] 페이지가 표시되고 테스트 실행이 완료된 후 수동 테스트 결과 페이지가 표시됩니다. 수동 테스트 이름에 DBCS 문자가 포함되어 있으면 두 페이지에 모두 수동 테스트가 올바르게 표시되지 않고 테스트의 원시 HTML처럼 보이는 것이 표시됩니다. 이 경우 테스트의 본문을 마우스 오른쪽 단추로 클릭한 다음 새로 고침을 선택하면 테스트가 몇 분간 응답하지 않다가 아무 것도 표시되지 않습니다.

이 문제를 해결하려면

Microsoft Word 형식의 수동 테스트 이름에 SBCS(싱글바이트 문자 집합) 문자만 사용합니다. 테스트의 설명 속성과 테스트 본문에는 DBCS 문자를 사용할 수 있습니다.

2.2   32비트 Visual Studio 2005 및 SQL Server 2005가 실행되는 64비트 컴퓨터에서 잘못된 버전의 msvsmon.exe가 실행되었습니다. 

Visual Studio 2005(x86) 및 SQL Server 2005(x86)가 설치된 64비트 컴퓨터에서는 SQLCLR 디버깅을 수행할 수 없습니다. 다음 메시지가 표시됩니다.

---------------------------
Microsoft Visual Studio
---------------------------
.NET 코드를 디버깅할 수 없습니다. ''<Machine Name>>''의 SQL Server 프로세스에 연결하지 못했습니다. Visual Studio 원격 디버깅 모니터(MSVSMON.EXE) 64비트 버전은 32비트 프로세스 또는 32비트 덤프를 디버깅할 수 없습니다. 대신 32비트 버전을 사용하십시오.
---------------------------
확인
---------------------------

컴퓨터의 운영 체제가 64비트이므로 msvsmon.exe 64비트 버전이 자동으로 실행됩니다. 하지만 두 응용 프로그램은 모두 32비트이므로 32비트 버전이 실행되어야 합니다. 이 문제는 현재 수정할 수 없는 아키텍처 문제입니다.

이 문제를 해결하려면

로컬 컴퓨터에서 SQLCLR 디버깅을 수행할 때 사용자가 수동으로 msvsmon.exe 32 비트 버전을 실행할 수 있습니다.

msvsmon.exe 32비트 버전이 자동으로 실행되도록 등록하지 않는 것이 좋습니다. 그렇지 않으면 다른 64비트 디버깅 시나리오가 수행되지 않습니다.

2.3   AuthorizationStoreRoleProvider: 권한 부여 관리자가 잘못되었거나 모호한 오류를 반환합니다. 

AuthorizationStoreRoleProvider는 권한 부여 관리자에 의존합니다. 권한 부여 관리자에서 반환하는 모든 오류 메시지에 문제의 근본 원인이 표시되는 것은 아닙니다. 잘못되었거나 모호한 것으로 알려진 오류 메시지는 다음과 같습니다.

"COMException (0x8007052b): 암호를 업데이트할 수 없습니다. 현재 암호로 제공된 값이 올바르지 않습니다."
이 오류는 액세스 거부 오류입니다. ASP.NET이 Windows Server 2003의 IIS 5.0 격리 모드 또는 IIS 5.0, Windows XP IIS 5.1에서 배포되고, 응용 프로그램이 Windows 통합 인증을 사용하도록 구성되어 있으며, 정책 파일이 현재 ASP.NET 응용 프로그램의 디렉터리 구조 내부에 있다는 조건이 모두 만족되면 이 오류가 발생할 수 있습니다. 로컬 컴퓨터 계정으로 실행되는 ASP.NET에서 원격 AD 또는 ADAM 인스턴스에 있는 정책 저장소에 액세스하려고 시도하는 경우에도 이 오류가 발생할 수 있습니다.

"사용할 수 있는 데이터가 더 있습니다."
이 오류는 정책 저장소를 찾을 수 없다는 뜻입니다. ADAM 인스턴스를 가리키는 연결 문자열이, 존재하지 않는 ADAM 파티션을 참조하는 경우에 이 오류가 발생할 수 있습니다. 예를 들어, "LDAP://localhost:4000/Cn=storename, DC=Partition1"이라는 연결 문자열에서 Partition1이 ADAM 인스턴스에 없는 경우 이 오류가 발생합니다.

"요청한 작업을 지정한 서버에서 수행할 수 없습니다."
이 오류는 지정한 서버를 찾을 수 없다는 뜻입니다. 연결 문자열이 존재하지 않는 서버를 가리키거나 AD 또는 ADAM이 수신하지 않는 포트 번호를 사용하는 경우 이 오류가 발생할 수 있습니다.

"ArgumentException: 매개 변수가 틀립니다."
이 오류 메시지는 사용자가 역할에 속해 있는지 여부를 확인하는 데 사용된 권한 부여 관리자의 LDAP 쿼리 그룹이 잘못되었음을 나타냅니다.

이 문제를 해결하려면

위에 나열된 각 오류 조건에 대해 가능한 원인을 검토합니다. 응용 프로그램의 구성이 가능한 원인 중 하나와 일치하는 경우 위 정보에 기초하여 응용 프로그램의 구성을 변경하거나 수정합니다.

2.4   공유 호스팅 컴퓨터에서 SQL Server Express 사용자 인스턴스를 사용할 수 없도록 설정해야 합니다.

ASP.NET 2.0의 여러 가지 새 응용 프로그램 서비스에 필요한 데이터베이스가 자동으로 만들어지도록 ASP.NET 2.0은 SQL Server Express 2005와 통합되어 있습니다. 이 기능은 SQL Server Express에서 대화형 사용자의 ID 또는 ASP.NET을 호스팅하는 작업자 프로세스의 ID로 실행되는 서버 프로세스를 생성하도록 지원하는 경우에만 사용할 수 있습니다. 공유 호스팅 서버와 같은 신뢰할 수 없는 환경에서는 ASP.NET 응용 프로그램 간에 의도하지 않은 데이터 공유가 발생하는 것을 피하기 위해 SQL Server 작업자 프로세스를 생성하는 기능을 사용할 수 없도록 설정해야 합니다.

이 문제를 해결하려면

독립 실행형 설치 관리자를 사용하여 SQL Server Express를 설치하는 경우에는 고급 설치 옵션을 사용하여 사용자 인스턴스에 대한 지원을 명시적으로 사용할 수 없도록 설정할 수 있습니다.

또는 다음과 같이 직접 기존 SQL Server Express 설치에 대한 사용자 인스턴싱을 사용할 수 없도록 설정할 수 있습니다.
1. 로컬 컴퓨터 관리자로 로그인한 다음 cmd.exe를 실행하여 명령 창을 엽니다.
2. PATH 환경 변수에 포함되어 있는 디렉터리에 osql.exe가 없으면 osql.exe를 포함하는 SQL Server Express 디렉터리로 디렉터리를 변경합니다.
3. osql –E –S .\sqlexpress를 사용하여 SQL Server의 부모 인스턴스에 연결합니다.
4. 다음 SQL 명령을 실행합니다.
exec sp_configure ''show advanced option'', ''1''
go
reconfigure with override
go
exec sp_configure ''user instances enabled'', 0
     go
reconfigure with override
go

2.5   폼 인증에 대한 영구 쿠키에서는 이제 세션 기반 쿠키와 동일한 시간 제한 설정을 사용합니다. 

이전 버전의 ASP.NET에서는 영구 폼 인증 쿠키의 수명이 50년으로 하드코딩되어 있었습니다. ASP.NET 2.0에서는 영구 폼 인증 쿠키의 만료 날짜가 현재 날짜 시간에 구성의 "timeout" 특성 값을 더한 값으로 설정됩니다. 즉, 기본적으로 영구 쿠키의 수명은 30분이 됩니다. 수명을 보다 길게 만들려면 "timeout" 특성 값을 늘려야 합니다. 이렇게 하면 ASP.NET 2.0에서는 세션 기반 쿠키와 영구 쿠키에 저장된 폼 인증 티켓이 새로운 시간 제한 값을 사용합니다.

이 문제를 해결하려면

각 영구 쿠키마다 다른 시간 제한 값을 사용하려는 개발자의 경우에는 처음에 FormsAuthentication.SetAuthCookie와 같은 메서드를 사용하여 쿠키를 설정한 다음 폼 인증 쿠키에 대한 참조를 가져옵니다. 그런 다음 Response.Cookie‎s[FormsAuthentication.FormsCookieName]에 대한 호출을 통해 쿠키에 대한 참조를 가져옵니다. 마지막으로 결과 HttpCookie에 대한 만료 속성을 다른 값으로 설정합니다.

2.6   AuthorizationStoreRoleProvider의 DeleteRole 메서드 동작이 잘못되었습니다. 

존재하지 않는 역할을 삭제하려고 하면 공급자의 DeleteRole 메서드가 "요소가 없습니다."라는 예외를 잘못 throw합니다. 공급자는 false를 대신 반환해야 합니다. 또한 기존 사용자가 포함되어 있는 역할을 삭제하려고 하면 공급자는 예외를 throw하는 대신 false를 반환합니다.

이 문제를 해결하려면

1. 공급자의 DeleteRole 메서드에 대한 모든 호출을 try-catch 블록 안에 래핑합니다. 이렇게 하면 채워진 역할을 삭제할 때 예외를 다시 사용하도록 설정하는 이후의 수정 내용이 기존 코드에 영향을 주지 않습니다.
2. 역할을 삭제하기 전에 해당 역할이 있는지 먼저 확인합니다.

2.7   XML serialization 및 기본이 아닌 응용 프로그램 ID를 사용하면 ASP.NET 프로필 기능이 실패할 수 있습니다. 

ASP.NET 프로필 기능에 대한 기본 속성 serialization 메커니즘은 XML serialization입니다. ASP.NET 프로세스 ID가 ASPNET(IIS 5.0 및 IIS 5.1의 경우) 또는 NETWORK SERVICE(IIS 6의 경우)가 아니면 "InvalidOperationException: 임시 클래스를 생성할 수 없습니다."라는 예외가 발생하여 XML serialization 프로세스가 실패합니다. 응용 프로그램 가장을 사용해도 동일한 문제가 발생합니다. 이러한 예외는 XmlSerializer가 임시 클래스 파일을 %windir%\temp 디렉터리에 쓰므로 발생합니다. 기본적으로 이 디렉터리는 기본 ASP.NET 계정에 대해 "폴더 보기/데이터 읽기" 권한만 부여합니다. 기본이 아닌 ASP.NET 계정은 임시 파일을 이 디렉터리에 쓸 수는 있지만 이후에 XmlSerializer에서 사용할 임시 클래스를 찾는 데 필요한 권한은 없습니다.

이 문제를 해결하려면

보안 환경을 위해 개발자는 다른 serialization 메커니즘(이진 serialization 또는 문자열 serialization 중 하나)을 사용해야 합니다. 응용 프로그램 간에 임시 클래스 파일을 실수로 공유할 가능성이 높지 않은 응용 프로그램에는 작업자 프로세스 또는 응용 프로그램 가장 ID에 %windir%\temp 디렉터리에 대한 "폴더 보기/데이터 읽기" 권한을 부여할 수 있습니다.

2.8   SSE 사용 시의 ASP.NET 세션 상태 제한 사항 

SSE는 ASP.NET SQL Server 기반 세션 상태의 개발 환경에서만 사용해야 합니다. 이는 SSE에 SQL Server 에이전트 서비스가 함께 설치되지 않기 때문입니다. 따라서 세션 상태 정리 작업이 실행되지 않으며 세션 상태 데이터는 데이터베이스에 누적됩니다. SSE에 연결한 다음 "EXECUTE DeleteExpiredSessions" 명령을 실행하여 만료된 세션을 직접 정리할 수 있습니다.

이 문제를 해결하려면

SQL Server 2005 표준 버전 중 하나를 프로덕션 응용 프로그램으로 사용합니다.

2.9   AuthorizationStoreRoleProvider: ApplicationName의 기본값으로 인해 권한 부여 관리자에서 오류가 발생합니다. 

권한 부여 관리자는 응용 프로그램 이름에 "/" 문자를 허용하지 않습니다. 구성에 applicationName이 설정되지 않은 경우 AuthorizationStoreRoleProvider는 다른 ASP.NET 공급자와 같은 논리를 사용하여 applicationName의 기본값을 결정합니다. 따라서 ASP.NET에서는 기본값이 "/" 문자로 시작하게 됩니다.

이 문제를 해결하려면

ASP.NET 응용 프로그램에서 AuthorizationStoreRoleProvider를 사용할 때는 반드시 구성에서 applicationName 특성을 설정합니다.

2.10   Windows 98 및 Windows ME에서 웹 서비스를 사용하는 응용 프로그램을 디버깅하면 응용 프로그램이 응답하지 않습니다. 

Windows 98 또는 Windows ME에서 웹 서비스를 사용하는 응용 프로그램을 디버깅할 경우 Visual Studio 2005에서 응용 프로그램이 지연됩니다.

이 문제를 해결하려면

디버거 구성 요소 csm.dll을 비활성화하고 중단점을 사용하여 웹 서비스를 중지합니다.

csm.dll을 비활성화하려면 다음 단계를 수행합니다.

1) Windows 시작 메뉴에서 실행을 선택합니다.
2) 실행 대화 상자에서 regedit.exe를 입력합니다.
3) HKEY_CLASSES_ROOT\CLSID\{12A5B9F0-7A1C-4FCB-8163-160A30F519B5}로 이동합니다.
4) InprocServer32\(기본값)의 값이 '' <drive>:\Program Files\Common Files\Microsoft Shared\VS7Debug\csm.dll''인지 확인하여 해당 레지스트리 키를 사용하고 있는지 확인합니다.
5) 레지스트리 키(HKEY_CLASSES_ROOT\CLSID\{12A5B9F0-7A1C-4FCB-8163-160A30F519B5})를 삭제합니다.

2.11   C# 코드 조각 바로 가기에 간격 없음 표시를 포함할 수 없습니다.  

C# 코드 조각은 .snippet 파일 내에 XML로 정의됩니다. 스키마에 사용할 수 있는 태그 중 하나는 <Shortcut></Shortcut> 태그입니다. 바로 가기를 사용하여 코드 조각을 신속하게 삽입할 수 있습니다. 코드 조각을 삽입하려면 바로 가기 문자열을 입력한 다음 Tab 키를 누르기만 하면 됩니다.

바로 가기 문자열 안에는 많은 유니코드 문자를 사용할 수 있지만 복잡한 스크립트 언어에 사용된 간격 없음 표시는 유효한 바로 가기 문자로 인식되지 않습니다. 즉, 복잡한 스크립트 언어의 일부 문자열은 바로 가기로 사용할 수 없습니다. 바로 가기에 간격 없음 표시가 포함된 경우 바로 가기 문자열을 입력하고 Tab 키를 누르면 탭 문자가 삽입되고 코드 조각은 삽입되지 않습니다.
참고: IntelliSense에는 코드 조각 바로 가기가 나타납니다.

이 문제를 해결하려면

1. 간격 없음 표시를 포함하지 않는 유니코드 바로 가기 이름을 선택합니다.
2. 바로 가기를 사용하는 대신 코드 조각 선택 UI를 통해 코드 조각을 삽입합니다.

2.12   System.Net에서 DNS 확인을 수행하기 위해 호출한 관리되지 않는 API의 시간 제한보다 DNS 확인에 대한 시간 제한이 적은 경우 DNS 확인 시간을 제한하는 논리가 제거되었습니다. 

이전 버전의 .NET Framework에서는 긴 네이티브 시간 제한을 피하기 위해 System.Net의 DNS가 DNS 형식에 시간 제한 논리를 추가했습니다. 정확한 DNS 시간 제한이 없으면 다른 웹 요청에 대해 정확한 시간 제한을 설정할 수 없습니다. 그러나 이 시간 제한을 구현하기 위해 DNS 확인이 별도의 스레드에 오프로드됩니다. 스레드 풀 수준이 낮으면 시간이 초과될 때까지 DNS 확인이 사용 가능한 스레드를 기다리므로 예외가 throw됩니다. 이 예외를 피하기 위해 DNS 시간 제한 논리가 제거되었습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

2.13   SqlCacheDependency는 System.Data.SqlClient.SqlDependency.Start에 대한 호출을 통해 초기화해야 합니다. 

SQL Server 2005에서의 쿼리 알림 작동 방법이 변경됨에 따라 개발자는 SqlCacheDependency를 사용하기 전에 SqlDependency에 대해 한 번 이상 Start 메서드를 호출해야 합니다. Start를 호출할 논리적 위치는 global.asax에 있는 웹 응용 프로그램의 Application_Start 메서드 내부입니다.

void Application_Start(object sender, EventArgs e)
{
System.Data.SqlClient.SqlDependency.Start("connection string");
}

연결 문자열은 SqlCacheDependency에 사용할 명령을 실행할 때 사용할 연결 문자열과 동일해야 합니다.

2.14   System.Net에서 WebClient.UploadValues() 호출 시 더 이상 CRLF 문자를 추가하지 않습니다.  

이전 버전의 .NET Framework에서는 WebClient.UploadValues()를 호출하면 업로드된 콘텐츠에 CRLF가 추가되어 서버 응용 프로그램 오류가 발생했습니다. CRLF 문자는 HTML 4.01 사양에 설명된 것처럼 application/x-www-form-urlencoded 콘텐츠 형식 인코딩 스키마를 위반합니다. 따라서 CRLF가 더 이상 추가되지 않습니다.

이 문제를 해결하려면

WebClient.UploadData()를 사용하여 CRLF를 추가하고 응용 프로그램을 다시 컴파일하거나 서버 응용 프로그램에서 CRLF 문자를 사용하지 않도록 수정합니다.

2.15   UriBuilder에서 Fragment 속성 또는 Query 속성을 설정한 다음 더 이상 해당 속성을 지우지 않습니다.  

UriBuilder는 URI 인스턴스를 부분별로 빌드할 수 있도록 하는 형식입니다. 이전 버전의 .NET Framework에서는 Query 속성과 Fragment 속성을 동시에 설정할 수 없었습니다. 이 오류는 버전 2.0에서 수정되었습니다. 이제 실수로 필드를 지우는 일 없이 Query 속성과 Fragment 속성을 설정할 수 있습니다. 이전 동작으로 작동하는 응용 프로그램에서는 잘못된 동작을 방지하기 위해 응용 프로그램 논리를 조정해야 할 수 있습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

2.16   응용 프로그램 구성 파일의 system.net 요소에 있는 값을 적용하기 전에 요청되는 권한이 변경되었습니다.  

응용 프로그램 구성 파일의 System.Net 요소에 있는 설정을 적용하는 데 필요한 권한이 이전 버전의 .NET Framework에서와 다르게 변경되었습니다. 구성 파일의 값을 적용하는 데 필요한 권한은 이제 코드의 설정을 변경할 때 관련 속성에 필요한 권한과 동일합니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

2.17   FTP 요청을 보낸 다음 SSL(FTP)을 통해 다른 FTP 요청을 동일한 디렉터리로 보내면 "파일을 찾을 수 없습니다."라는 예외가 throw됩니다. 

응용 프로그램에서 FTP 요청을 서버로 보낸 다음 SSL을 사용하여 다른 FTP 요청을 동일한 서버 및 경로로 보내면 두 번째 요청이 실패합니다. "파일을 찾을 수 없습니다." 예외가 throw됩니다. 그러나 두 번째 요청을 동일한 경로로 보내지 않으면 요청이 성공적으로 수행됩니다.

2.18   해당 서비스 지점이 프록시 서버인 경우에만 WebRequest.ServicePoint.Address가 제한 없는 웹 사용 권한을 요청합니다.  

이 새로운 요청으로 인해 부분 신뢰로 실행되는 응용 프로그램이 네트워크 프록시 주소를 검색할 수 없습니다. ServicePoint.Address API를 사용하는 부분 신뢰 응용 프로그램에는 주소가 프록시 서버를 가리키는 경우 SecurityException이 발생할 수 있습니다.

이 문제를 해결하려면

HttpWebRequest.Address를 사용합니다.

2.19   Visual Studio 및 .NET Framework에 대한32비트 및 64비트 동작 간 패리티의 예외 사항 

1. IA64 WOW64용 Front Page Server Extensions    

.NET Framework 1.1을 실행하는 원격 IA64 컴퓨터에서 .NET Framework 1.1을 사용하여 웹 사이트를 제작할 경우에는 FrontPage 메커니즘이 지원되지 않습니다. 기본적인 일부 기능이 파일 공유 메커니즘을 통해 작동합니다.

2. J#은 네이티브 64비트에서의 실행을 지원하지 않습니다. J# 코드는 64비트 플랫폼의 WOW64에서만 실행할 수 있습니다.    

3. .NET Framework 2.0 64비트에서는 SQL Server Express를 지원하지 않습니다.

4. IA64 WOW64의 .NET Framework 1.1에서 실행되며 로드가 많은 ASP.NET 응용 프로그램의 경우 성능이나 확장성이 보장되지 않습니다.

5. 데이터 중단점은 IA64 WOW64에서 실행되는 Visual Studio에서 작동하지 않습니다.    

6. Visual Studio 2005의 편집하며 계속하기 디버거 기능은 네이티브 64비트 환경에서 작동하지 않고 64비트 WOW 환경에서 작동합니다.

7. Visual Studio 2005의 VC ATL 예외 사항은 다음과 같습니다.    

- 빌드 시스템에서 64비트를 대상으로 하는 dll을 wow64에서 등록하지 않습니다.

- 64비트 컴퓨터에서 기본 ATL 서버 프로젝트를 디버깅하면 ""%1은(는) 올바른 Win32 응용 프로그램이 아닙니다.""라는 오류가 발생합니다.

- 64비트 구성을 사용하는 ATL 서버 프로젝트에 대해 디버깅할 실행 파일과 URL이 미리 채워지지 않습니다.

- 64비트 ATL 서버 프로젝트를 디버깅할 때 사용자가 지정한 .srf 파일을 Internet Explorer에서 제공하지 않습니다.

- 64비트 ATL 서버 구성의 기본 디버거 형식이 웹 서비스 디버거가 아니라 로컬 Windows 디버거입니다.

- 디버깅 속성이 프로젝트의 새 구성에 전파되지 않습니다. 즉, 예를 들어 ATL 서버 프로젝트를 x86으로 시작한 다음 이 프로젝트에 대해 64비트 구성을 만들면 디버기를 Internet Explorer로 변경하지 않는 한 디버깅이 작동하지 않습니다.


8. 네이티브 64비트 환경에서는 interop 디버깅(관리 및 비관리 혼합 모드 디버깅)이 지원되지 않습니다. interop 디버깅은 64비트 WOW 환경에서 작동합니다.

9. 64비트에서는 Re-entrancy, LoaderLock, PInvokeStackImbalance 등 일부 MDA를 사용할 수 없습니다.

10. IA64 및 x64 C++ 컴파일러에서는 MMX 내장 개체를 사용할 수 없습니다.

11. IA64 및 x64 C++ 컴파일러에서는 인라인 어셈블리를 지원하지 않습니다.

12. x64 MASM에서는 대부분의 상위 수준 언어 구문을 지원하지 않습니다.
MASM에서는 IA64를 사용할 수 없지만 Intel 어셈블러(ias.exe)가 제공됩니다.

13. Visual Studio 2005에서는 x64 및 IA64 VC++ 컴파일러의 VC++ 컴파일러 스위치 /ARCH:SSE를 사용할 수 없습니다.

14. 64비트 자식 프로세스 수행 시 WOW64에서 실행하면 System.Diagnostics.Process.MainModule 및 System.Diagnostics.Process.Modules API가 실패합니다.

15. GUID/CLSID가 동일한 32비트 및 64비트 COM+ 서비스 구성 요소는 동시에 등록할 수 없습니다.

16. 64비트 SDK에는 네이티브 DBGCLR이 포함되어 있지 않습니다. DBGCLR은 WOW64 전용이 됩니다.

17. 64비트 SDK에는 네이티브 DEXPLORE.EXE가 포함되어 있지 않습니다. DEXPLORE.EXE는 WOW64 전용이 됩니다.

18. x64 및 IA64에는 부트스트래퍼 매니페스트 패키지가 없습니다.

ClickOnce 또는 다른 응용 프로그램에는 64비트 부트스트래퍼가 없습니다. .NET Framework가 설치되지 않은 64비트 컴퓨터에서 ClickOnce 응용 프로그램을 설치하려고 하면 "64비트 운영 체제에서는 이 버전의 .NET Framework 2.0을 지원하지 않습니다. 응용 프로그램 공급업체에 문의하십시오."라는 오류 메시지가 표시되며 실패합니다.

32비트 전용으로 작성되어 WOW64에서 실행할 수 있는 응용 프로그램의 경우에도 이러한 오류가 발생합니다.

19. IA64에는 Visual Studio를 설치할 수 없습니다.    

IA64에는 Visual Studio 2005를 설치할 수 없습니다. IA64에서는 디자인 타임이 지원되지 않습니다. Visual C++에는 네이티브 IA64 명령줄 도구 설치 관리자가 포함될 예정입니다.

20. Visual Studio Team System에서만 IA64를 대상으로 하는 응용 프로그램을 빌드할 수 있습니다.    


21. 64비트에서는 blittable 형식의 P/Invoke 시그니처가 다르게 처리됩니다. 
64비트에서는 P/Invoke가 다르게 구현되므로 우연히 32비트에서 작동한 잘못된 P/Invoke 시그니처가 64비트에서 작동하지 않는 경우가 있기 때문입니다.

22. 64비트에서는 Visual Studio 2005 Tools for Office를 지원하지 않습니다.
    

2.20   C# 웹 사이트에서 리팩터링 작업을 수행할 때 실제로는 오류가 없는데 빌드 오류가 보고될 수 있습니다. 

경우에 따라 빌드 오류가 없는 C# 웹 사이트에서 리팩터링 명령을 수행할 때 프로젝트 또는 여기에 종속되어 있는 프로젝트 중 하나가 현재 빌드되지 않으며 참조가 업데이트되지 않았음을 나타내는 경고가 표시될 수 있습니다.
이 대화 상자는 계속 또는 미리 보기 단추를 클릭하여 무시해도 안전합니다. 리팩터링이 성공적으로 수행되며 모든 참조가 업데이트됩니다.

다음은 이 경고가 표시되는 일반적인 프로젝트 구성의 예입니다.
- 웹 디렉터리에 global.asax 파일이 포함되고 App_Code 디렉터리에 global.asax.cs 파일이 포함된 이전 버전의 Visual Studio에서 마이그레이션된 웹 프로젝트
- 웹 페이지에서 웹 사용자 정의 컨트롤을 참조하고 웹 사용자 정의 컨트롤은 App_Code 디렉터리에 선언된 형식을 참조하는 웹 프로젝트

이 문제를 해결하려면

알려진 해결 방법이 없습니다. 그러나 이 경고는 무시해도 안전합니다.

2.21   System.Net은 이제 자체 FTP 구성 요소를 사용하는 응용 프로그램을 중단할 수 있는 기본 FtpWebRequest 구현을 등록합니다.  

.NET Framework 2.0 이전 버전의 응용 프로그램에서는 System.Net의 확장 가능한 플러그형 프로토콜 프레임워크를 사용하여 FTP 요청을 처리하는 구성 요소를 등록할 수 있었습니다. 다른 웹 요청을 처리하기 위한 구성 요소는 해당 구성 요소에 특정 URI 접두사를 연결하여 등록됩니다. 해당 접두사와 일치하는 웹 요청은 모두 해당 구성 요소에 의해 처리됩니다. .NET Framework 2.0의 System.Net에서는 이제 기본적으로 "ftp:" 접두사로 등록되는 FtpWebRequest 구성 요소를 지원합니다. 이 접두사로 등록되는 이 릴리스 이전의 모든 응용 프로그램은 이제 해당 접두사(FTP)가 이미 사용되고 있으므로 중단될 수 있습니다.

이 문제를 해결하려면

사용자 지정 FTP 구성 요소를 등록하기 전에 먼저 응용 프로그램 구성 파일을 업데이트하여 기본 FTP 프로토콜 구성 요소를 제거합니다.
<system.net>
<webRequestModules>
<remove prefix = "ftp:" />
</webRequestModules>
</system.net>

2.22   .NET Framework 2.0에서 빈 System.Net 태그가 machine.config 파일에 있으면 GlobalProxySelection.Select가 버전 1.1에서와 다르게 작동합니다. 

.NET Framework 버전 1.1에서 machine.config 파일에 빈 System.Net 요소를 지정하면 GlobalProxySelection.Select에서 사용할 프록시가 없음을 나타내는 빈 웹 프록시 인스턴스를 반환합니다. 버전 2.0에서는 이러한 경우 Internet Explorer에 지정된 것과 동일한 시스템 프록시 설정이 기본적으로 사용됩니다.

이 문제를 해결하려면

아래와 같이 machine.config 파일을 수정하여 기본 프록시를 사용할 수 없도록 설정합니다.
<system.net>
<defaultProxy enabled="false" />
</system.net>

2.23   System.Uri가 호스트에 IPv6 범위 ID를 포함시키지 않습니다.  

이전 버전의 .NET Framework에서 IPv6 주소를 사용하여 URI 인스턴스를 만들면 범위 ID가 항상 호스트 주소에 포함되었습니다. 범위 ID는 로컬 네트워크 어댑터의 인덱스를 나타내며 원격 호스트에는 아무 의미가 없습니다. 또한 범위 ID는 해당 구문에 ''%'' 문자를 사용하며 이 문자는 URI 이스케이프 형식인 ''%hh''와 충돌합니다. 호스트에 범위 ID를 포함시키면 다른 URI 파서 및 해결 프로그램과 상호 운영될 수 있는 System.Uri의 기능이 중단됩니다. 버전 2.0에서는 System.Uri가 더 이상 URI 인스턴스의 IPv6 호스트에 범위 ID를 포함시키지 않습니다. 또한 System.Uri는 IPv6 호스트 주소와 함께 범위 ID를 반환하는 새로운 속성인 DnsSafeHost를 추가했습니다.

이 문제를 해결하려면

IPv6 호스트 주소와 함께 범위 ID를 반환하는 Uri.DnsSafeHost를 사용합니다.

2.24   System.Transactions 구성을 통해 클러스터를 원격 프록시로 지정하면 클러스터 장애 조치(Failover)를 수행하는 동안 TransactionException이 throw될 수 있습니다. 

DistributedTransactionManagerName을 클러스터로 설정하여 구성에서 클러스터를 원격 프록시로 지정하면 클러스터 장애 조치(Failover)를 수행하는 동안 TransactionException이 throw될 수 있습니다.

이 문제를 해결하려면

클러스터를 원격 프록시로 지정하려면 구성 요소 서비스 MMC를 사용하여 클러스터를 원격 MSDTC로 사용하도록 MSDTC를 구성합니다.

2.25   IDE에서 다양한 작업 수행 시 "Microsoft C# 2005 IntelliSense에 문제가 발생했습니다."라는 메시지가 나타날 수 있습니다. 

경우에 따라 편집기에서 다양한 작업 수행 시 "Microsoft C# 2005 IntelliSense에 문제가 발생했습니다. 불편을 드려서 죄송합니다."라는 메시지가 나타날 수 있습니다. 이러한 오류 메시지는 소스 데이터를 검색할 수 없는 경우에도 나타납니다.

이 메시지를 트리거할 수 있는 작업의 예는 다음과 같습니다.
- 외부 별칭 바꾸기
- ''runat="server"'' 특성이 없는 웹 프로젝트에서 "모든 참조 찾기" 수행

이 오류 메시지는 사소한 오류 메시지입니다. 보고서 보내기 단추를 클릭하면 작업을 예상대로 안전하게 계속할 수 있으며 데이터가 손실되지 않습니다.

이 문제를 해결하려면

C# 언어 서비스의 모든 사소한 오류 메시지 표시를 해제할 수 있는 옵션에는 두 가지가 있습니다. 사소한 오류 메시지 표시를 해제하려면 다음 레지스트리 경로에서 레지스트리를 수정합니다.

[HKEY_CURRENT_USER\Software\Microsoft\VisualStudio\8.0\CSharp\Options\Editor]

(1) "Watson_ReportExceptions"=dword:00000001
지정된 값과 함께 위의 레지스트리 키를 추가하면 오류 보고가 완전히 해제됩니다.

참고: 이 레지스트리 키를 사용하여 C# 언어 서비스의 모든 사소한 오류 메시지를 해제하면 이 오류와 관련되지 않은 시나리오에 대한 피드백 수집을 방지할 수 있습니다.

(2) "Watson_DeferSendingUntilLater"=dword:00000000
지정된 값과 함께 위의 레지스트리 키를 추가하면 오류 메시지 표시가 해제되지만 피드백은 계속 Microsoft로 전송됩니다. 전송할 정보를 수집하는 동안에는 IDE가 짧은 기간 동안 응답하지 않습니다.

2.26   트랜잭션 확장 시 트랜잭션 DistributedIdentifier를 가져오는 동안 NullReferenceException이 throw되었습니다. 

트랜잭션이 확장되는 동안 트랜잭션에 대한 DistributedIdentifier를 가져오면 NullReferenceException이 throw될 수 있습니다.

이 문제를 해결하려면

이 문제는 다음 두 가지 방법을 통해 해결합니다.

트랜잭션에 대한 액세스가 동기화되었는지 확인합니다.

-또는-

DistributedIdentifier 속성을 확인하기 전에 트랜잭션이 확장되었는지 확인합니다.

2.27   웹 참조 추가를 사용하여 생성된 ASP.NET 웹 서비스 프록시는 서비스에 URL이 서로 다른 끝점이 여러 개 있더라도 모두 구성 파일에서 가져온 동일한 URL을 사용합니다. 

Visual Studio 2005에서 웹 참조를 추가하면 서비스의 URL이 구성 파일의 AppSettings 섹션에서 자동으로 선택됩니다. 웹 서비스에 URL이 서로 다른 끝점이 여러 개 있으면 여러 개의 프록시 형식이 생성되지만 모두 구성 파일에서 가져온 동일한 URL 값을 사용합니다.

이 문제를 해결하려면

다음 두 가지 방법이 있습니다.
1. WSDL 문서를 편집하고 각 서비스를 별도의 문서로 나눕니다.

-또는-
2. 구성 파일을 편집하여 각 웹 서비스에 키를 추가한 다음 System.Configuration.ConfigurationSettings.AppSettings를 사용하여 코드의 값을 읽습니다. 이러한 값을 사용하여 프록시 인스턴스에 URL 속성을 설정합니다.

2.28   생성된 ASP.NET 웹 서비스 프록시의 Nullable<T>에 대한 기본 지원 기능은 프록시를 다시 생성할 때 기존 코드를 중단할 수 있습니다. 

ASP.NET 웹 서비스에 대해 nullable="true" 특성이 포함된 스키마를 가져오면 생성된 프록시에 Nullable<T> 형식이 포함되지만 이전에는 해당 특성이 무시되었습니다. 이러한 변경으로 인해 응용 프로그램에서 디자인 타임 또는 런타임 중단이 발생할 수 있습니다.

이 문제를 해결하려면

가능한 해결 방법은 프록시 형식 다시 생성을 방지하거나, 새 Nullable<T> 패턴을 사용하여 코드를 다시 컴파일하거나, nullable="true" 특성을 사용하지 않도록 스키마를 변경하는 것입니다.

2.29   웹 서비스 프록시 인스턴스에 대해 프록시 속성을 null로 설정하면 요청이 서버로 직접 이동하지 않습니다. 

웹 서비스 프록시 인스턴스에 대해 프록시 속성을 null로 설정하면 요청이 모든 웹 프록시 서버 설정을 사용하지 않고 서버로 직접 이동합니다. 그러나 이 기능은 현재 작동하지 않습니다. 따라서 null 값이 무시되고 구성된 모든 웹 프록시 서버 설정이 대신 사용됩니다.

이 문제를 해결하려면

프록시 형식에서 파생하고 GetWebRequest 메서드를 재정의하여 기본 WebRequest에 프록시 속성을 직접 설정할 수 있습니다.

protected override WebRequest GetWebRequest(Uri uri)
{
WebRequest req = base.GetWebRequest(uri);
req.Proxy = this.proxy;
return req;
}

2.30   여러 버전의 .NET Framework에서 .NET Remoting 및 런타임 Serialization 사용 

한 버전의 .NET Framework에서 실행되는 응용 프로그램과 다른 버전에서 실행되는 응용 프로그램 간에 .NET Remoting 또는 런타임 Serialization을 사용하여 데이터를 교환하면 예외가 발생할 수 있습니다. 이러한 예외는 특정 형식이 서로 다른 Framework 버전 간에 호환되지 않음을 나타냅니다. 즉, 한 Framework 버전에서 다른 버전으로 해당 형식을 보낼 수 없습니다.

.NET Framework 2.0에는 이 문제를 해결하는 Version Tolerant Serialization이라는 기술이 포함되어 있습니다. 그러나 이전 버전의 Framework에서는 계속 이 문제가 발생할 수 있습니다. 따라서 일부 Version Tolerant Serialization 기능을 .NET Framework 1.1에 추가하는 패치가 나올 예정입니다. 이 패치를 설치하려면 서비스 팩 1이 필요합니다. 패치를 설치한 다음에는 이러한 버전 문제 없이 패치된 Framework가 .NET Framework 2.0에서 실행되는 응용 프로그램과 통신할 수 있게 됩니다. .NET Framework 1.0에 대해서는 이러한 패치가 제공될 계획이 없습니다.

Version Tolerant Serialization에서는 직접 또는 .NET Remoting을 통해 이진 Serialization을 사용하는 경우에만 버전 문제를 해결합니다. SoapFormatter 클래스를 통해 직접 또는 .NET Remoting을 통해 SOAP serialization을 여러 버전의 Framework에서 사용하는 경우에는 위에서 설명한 버전 문제가 계속 발생할 수 있습니다.

이 문제를 해결하려면

이 패치를 받으려면 http://support.microsoft.com/?kbid=907262에 있는 기술 자료 문서를 참조하십시오.

2.31   부분 신뢰에서는 System.Transactions 추적에 대해 기본이 아닌 추적 수신기를 지정할 수 없습니다. 

부분 신뢰에서는 구성의 System.Transactions 추적에 대해 특정 추적 수신기를 지정하는 작업을 지원하지 않으며 지정하면 예외가 throw됩니다.

이 문제를 해결하려면

부분 신뢰에서는 기본 추적 수신기가 지원되므로 구성에 수신기가 지정되어 있지 않으면 기본 수신기에서 추적을 catch하여 debug.outputstring에 출력합니다. 이러한 추적은 DBMon.exe를 사용하여 부분 신뢰에서 볼 수 있습니다.

2.32   .NET Framework 2.0으로 마이그레이션한 다음에는 웹 서비스 또는 XML Serialization 시나리오의 날짜 및 시간 계산이 올바르지 않을 수 있습니다. 

.NET Framework 2.0은 XML에서 날짜 및 시간을 읽고 쓰는 방법을 변경합니다. 이러한 변경은 주로 다음과 같은 시나리오에 영향을 미칩니다.
- 표준 시간대를 지정하지 않는 시간 또는 UTC 시간대 시간 사용
- 표준 시간대나 UTC 시간대를 지정하지 않고 시간 값을 XML에 기록하는 타사 소프트웨어와의 상호 운용성 시나리오

이러한 변경으로 인해 특정한 날짜 및 시간의 계산과 비교가 올바르지 않을 수 있습니다. 이러한 경우 이전 날짜/시간 동작으로 되돌려야 할 수 있습니다.

이 문제를 해결하려면

이전 날짜/시간 동작으로 되돌리려면 다음 구성 변경을 적용합니다.

<system.xml.serialization>
<dateTimeSerialization mode="Local" />
</system.xml.serialization>

2.33   SQL Server Express 및 IIS를 통한 ASP.NET 자동 데이터베이스 만들기를 위한 Windows 사용자 프로필 

SSE(SQL Server Express) 및 IIS를 사용하는 SQL Server 공급자에 대한 ASP.NET 자동 MDF 만들기 프로세스는 IIS가 로컬 ASP.NET 컴퓨터 계정으로 실행되거나 NT AUTHORITY\NETWORK SERVICE로 실행될 경우에만 작동합니다. 개발자가 Cassini, 즉 파일 기반 웹을 사용하여 대화식으로 개발하는 경우에도 자동 만들기 프로세스가 작동합니다. 그러나 다른 로컬 컴퓨터 계정이나 도메인 사용자 계정을 사용하여 IIS에 대한 개발을 진행하는 경우에는 이러한 계정에 웹 서버에서 사용할 수 있는 Windows 사용자 프로필이 없으므로 자동 데이터베이스 만들기 프로세스가 실패합니다.

이 문제를 해결하려면

이 경우에는 해결 방법이 없습니다. IIS 기반 웹 사이트에 대해 SSE를 통해 자동으로 데이터베이스를 만드는 작업은 ASPNET 및 NETWORK SERVICE 계정에 대해서만 수행할 수 있습니다.

2.34   SQL Server 7.0 또는 2000을 사용하는 ASP.NET 공급자의 유니코드 서로게이트 동작 

SQL Server를 사용하는 ASP.NET 공급자는 SQL Server 7.0 및 SQL Server 2000에서 제공하는 유니코드 서로게이트 지원 수준에 의해 제한을 받습니다. SQL Server 7.0 및 2000은 손실되는 데이터 없이 서로게이트 쌍을 저장하고 검색합니다. 그러나 서로게이트에 대한 언어적인 비교는 하지 않습니다. 이러한 버전의 SQL Server를 사용하는 경우 비교 작업을 하거나 고유성 확인을 할 때 서로게이트 문자는 무시됩니다. 즉, 예를 들어 SqlMembershipProvider는 서로게이트 문자만 포함하는 두 개의 사용자 이름을 동일한 것으로 간주합니다. 기존 사용자와 서로게이트 문자만 다른 사용자 이름으로 두 번째 사용자를 만들면 이 동작으로 인해 고유성 제약 조건 위반이 발생합니다.

이 문제를 해결하려면

이 버전의 SQL Server에는 알려진 해결 방법이 없습니다.

2.35   FileWebRequest.PreAuthenticate가 false만 반환합니다. 

WebRequest에서 상속되는 형식은 PreAuthenticate 속성을 상속합니다. 이 속성은 서버의 시도를 기다리지 않고 인증 정보를 요청과 함께 보낼 수 있도록 설정하는 데 사용됩니다. FileWebRequest는 사전 인증을 지원하지 않으므로 해당 PreAuthenticate 속성이 항상 false를 반환합니다. 이전 버전의 .NET Framework에서는 응용 프로그램에서 PreAuthenticate 속성을 true로 설정하면 해당 값이 나중에 쿼리될 때 true를 반환했습니다. 이제는 그렇지 않습니다. FileWebRequest의 PreAuthenticate 속성은 항상 false를 반환합니다.

이 문제를 해결하려면

FileWebRequest에 대해 PreAuthenticate 속성을 사용하지 않습니다.

2.36   .NET Remoting 및 SOAP Serialization에 제네릭 형식 사용 

.NET Remoting 기술은 이진 및 SOAP serialization을 모두 지원합니다. 즉, Remoting 메시지를 Microsoft 고유의 이진 형식이나 SOAP XML로 나타낼 수 있습니다. 그러나 .NET Framework 2.0의 새로운 기능인 제네릭 형식은 이진 serialization에만 사용할 수 있습니다. SOAP serialization에서의 제네릭 사용은 .NET Remoting을 통하든 SoapFormatter 클래스를 직접 사용하든 지원되지 않습니다.

이 문제를 해결하려면

이 경우에는 알려진 해결 방법이 없습니다.

2.37   C# 웹 사이트에서 리팩터링 작업을 수행할 때 실제로는 오류가 없는데 빌드 오류가 보고될 수 있습니다. 

경우에 따라 빌드 오류가 없는 C# 웹 사이트에서 리팩터링 명령을 수행할 때 프로젝트 또는 여기에 종속되어 있는 프로젝트 중 하나가 현재 빌드되지 않으며 참조가 업데이트되지 않았음을 나타내는 경고가 표시될 수 있습니다.
이 대화 상자는 계속 또는 미리 보기 단추를 클릭하여 무시해도 안전합니다. 리팩터링이 성공적으로 수행되며 모든 참조가 업데이트됩니다.

다음은 이 경고가 표시되는 일반적인 프로젝트 구성의 예입니다.
- 웹 디렉터리에 global.asax 파일이 포함되고 App_Code 디렉터리에 global.asax.cs 파일이 포함된 이전 버전의 Visual Studio에서 마이그레이션된 웹 프로젝트
- 웹 페이지에서 웹 사용자 정의 컨트롤을 참조하고 웹 사용자 정의 컨트롤은 App_Code 디렉터리에 선언된 형식을 참조하는 웹 프로젝트

이 문제를 해결하려면

알려진 해결 방법이 없지만 이 경고는 무시해도 안전합니다.

2.38   .NET Remoting 또는 이진 serialization에서 제네릭 형식을 사용하면 버전 관리 기능이 작동하지 않는 경우가 있습니다. 

.NET Remoting 및 이진 serialization은 느슨하게 결합된 모드(FormatterAssemblyStyle을 Simple로, includeVersions를 False로, strictBinding을 False로 설정하여 선택함)에서 작동할 수 있습니다. 이 모드에서는 serialize된 형식의 어셈블리 버전이 deserialization 시에 형식이 로드되는 어셈블리의 버전과 일치할 필요가 없습니다. 이 기능은 버전 관리를 손쉽게 할 수 있도록 하기 위해 제공합니다. 예를 들어, 클라이언트를 업데이트할 필요 없이 .NET Remoting 서버를 업데이트할 수 있습니다.

그러나 이 메커니즘이 실패하는 경우가 있습니다. 특히 제네릭 형식을 사용할 경우 제네릭 매개 변수 형식의 어셈블리 버전이 변경되면 느슨하게 결합된 모드에서도 deserialization에 실패할 수 있습니다. 예를 들어, MyType2 형식의 형식 매개 변수와 함께 제네릭 형식 MyType1을 deserialize할 경우 deserialization 시점에 MyType2를 포함하는 어셈블리의 버전이 serialization 시점의 버전과 다르면 deserialization에 실패할 수 있습니다.

이 문제를 해결하려면

이 제한을 해결하려면 버전 관리 시나리오가 중요한 경우 .NET Remoting/이진 serialization에서 제네릭을 사용하지 않거나, .NET Framework의 어셈블리 바인딩 리디렉션 기능을 사용하여 존재하지 않는 어셈블리 버전을 로드하는 요청을 deserialization을 수행하는 컴퓨터에 실제로 존재하는 버전으로 리디렉션합니다. 또는 AssemblyResolve 이벤트를 사용하여 어셈블리 로드에 실패하는 시점을 감지하고 부분 이름만 사용하여 어셈블리 로드를 다시 시도할 수도 있습니다.

2.39   FtpWebRequest에서 KeepAlive를 사용하는 경우 디렉터리 나열 명령을 실행하고 파일 검색 명령을 실행하면 요청과 함께 전송되는 파일 경로가 변경됩니다. 

FtpWebRequest에서 KeepAlive 속성이 true로 설정된 경우 디렉터리 나열 명령을 실행하고 파일 검색 명령을 실행하면 요청과 함께 전송되는 파일 경로가 변경됩니다. 요청된 파일의 경로는 추가 경로 구분 문자와 함께 추가됩니다. 이 동작은 일부 FTP 서버에만 영향을 주며 해당 서버에서는 파일을 찾을 수 없다는 오류가 반환됩니다.

이 문제를 해결하려면

디렉터리 나열 명령을 실행하는 요청에서 KeepAlive 속성을 false로 설정한 다음 이후의 검색에서 KeepAlive를 다시 true로 설정합니다.

3. 스마트 장치 프로그래밍 기능

3.1   DLL 함수의 F11 키가 X86 스마트 장치 프로젝트에서 작동하지 않습니다. 

1. x86 플랫폼을 대상으로 하는 dll에서 내보낸 함수 DllFunc와 이 함수의 코드 조각을 사용하여 Win32 스마트 장치 프로젝트 Dll을 만듭니다.
2. 이 dll에서 LoadLibrary를 수행하고 동일한 솔루션에 추가된 DllFunc를 호출하는 Win32 스마트 장치 프로젝트 exe를 만듭니다. 이 프로젝트가 시작 프로젝트로 설정되어 있는지 확인합니다.
3. 솔루션을 컴파일, 배포 및 디버그합니다.
4. DllFunc를 한 단계씩 실행(F11 키)합니다. GetProcAddress에서 가져온 이 특수한 DllFunc() 및 x86 플랫폼에서만 F11 키가 F10 키로 전환됩니다.

이 문제를 해결하려면

디버거 창에서 DllFunc를 표시하여 16진수 주소를 가져온 다음 디스어셈블리에 중단점을 설정합니다.

3.2   네이티브 프로세스에 관리되는 연결에서 오류를 반환하지 않습니다. 

1. 네이티브 콘솔 스마트 장치 프로젝트를 만듭니다.
2. Ctrl 키를 누른 채로 F5 키를 누릅니다.
3. 도구, 프로세스에 연결을 차례로 선택합니다.
4. 스마트 장치 전송과 대상 장치를 선택합니다.
5. 디버그 엔진 선택 대화 상자에서 관리되는 디버거를 선택합니다.
6. 네이티브 프로세스 및 연결을 선택합니다.
7. 더 이상 메시지가 표시되지 않습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

3.3   중단 모드에서 기존 중단점에 필터를 적용하면 중단점이 무시됩니다. 

1) 다음 코드로 네이티브 응용 프로그램을 만듭니다.
void foo(void)
{        
}        

int _tmain(int argc, _TCHAR* argv[])
{
    int i = 0;

    foo();

    return 0;
}
2) "return 0;"에 위치 중단점을 설정합니다.
3) 디자인 타임에 foo()에 함수 중단점을 설정합니다.
4) F10 키를 눌러 응용 프로그램을 중단 모드로 가져옵니다.
5) 중단점 창을 열고 ProcessName 또는 ThreadName 필터를 포함하여 함수 중단점의 필터 속성을 편집합니다.
6) 계속합니다(F5 키).
7) 함수 중단점이 적중되지 않고 대신 "return 0" 문에서 중단됩니다.

위의 시나리오에서는 중단 모드에서 필터 속성을 편집하여 디자인 타임 중단점을 수정하면 중단점이 무시된다는 것을 보여 줍니다. 이는 모든 종류의 중단점에 적용됩니다.

이 문제를 해결하려면

디자인 타임에 중단점을 설정하고 필터를 적용합니다. 디자인 타임에는 ThreadId 및 ProcessId를 알 수 없으므로 ProcessName 및 ThreadName 필터에만 중단점이 적용됩니다.

3.4   네이티브 디버깅에서 루프 구문의 본문이 소스 한 줄에 걸쳐 있으면 F10 및 F11 키는 while 루프의 본문과 관련 구문을 프로시저 단위로 실행하도록 변환됩니다. 

F10 ¹× F11 키는 다음 예제에서 설명된 시나리오대로 제대로 작동하지 않습니다.

예제 코드 조각

1 int i = 0;
2 while (i < 1000) { i++; }
3 return 0;

단계:
-첫째 줄에서 F9 키를 누른 다음 중단점이 이 줄에서 적중되면 F10 키를 누릅니다.
-이제 둘째 줄로 제어가 이동합니다.
-F10 키를 다시 누릅니다.

위 단계를 수행하면 둘째 줄이 아니라 셋째 줄에서 디버거가 중지/중단됩니다. 즉, F10 키가 반복되어 둘째 줄의 중단점이 무시됩니다.
이는 소스 한 줄에 걸쳐 있는 모든 루프 구문에 적용됩니다.

이 문제를 해결하려면

while 루프(둘째 줄)이 있는 소스 줄에 F9 키로 중단점을 설정합니다. 그러면 while 루프를 단계별로 실행하는 동안 둘째 줄에서 F10 키를 누를 때마다 디버거가 중단됩니다(i가 1000까지 증가할 때까지) .

-또는-

코드를 변경할 수 있는 경우 위 코드를 다음과 같이 다시 구성하면 모두 예상한 대로 작동합니다.
    1 int i = 0;
    2 while (i < 1000)
    3 { i++; }
    4 return 0;

3.5   스마트 장치 응용 프로그램에서 네이티브 어설션 대화 상자의 단추가 화면 밖에 렌더링될 수 있습니다. 

Pocket PC 또는 Smartphone의 Visual Studio 2005 C++ 스마트 장치 응용 프로그램에서 어설션 대화 상자가 throw되면 대화 상자의 단추가 화면 밖에 렌더링될 수 있습니다.

이 문제를 해결하려면

Pocket PC 또는 Smartphone의 스크롤 단추/키를 사용하여 직접 해당 단추로 스크롤합니다.

3.6   스마트 장치 프로젝트의 "변경된 내용만 복사" 속성의 의미 

스마트 장치 프로젝트에서는 Win32 버전을 비교하여 dll 또는 exe 파일이 최신 파일인지 여부를 확인합니다.
- 장치측 버전이 데스크톱 버전보다 낮으면 파일이 복사됩니다.
- 장치측 버전이 데스크톱 버전보다 높으면 파일이 복사되지 않습니다.
- 체크섬이 다르면 파일이 복사됩니다.

dll과 exe를 제외한 파일의 최신 상태는 전적으로 체크섬에 따라 달라집니다.
최신 상태는 타임스탬프나 크기와 상관 없습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

3.7   Visual Studio 2005는 TCP/IP 장치에 연결하는 동안 오류가 있을 경우 ActiveSync 장치에 연결합니다.  

특정 장치(예: PPC)가 ActiveSync를 통해 연결되어 있고 TCP/IP를 통해 WinCE 장치(예: CEPC)에 연결하려고 할 경우 TCP/IP를 통해 WinCE 장치에 연결할 수 없으면 Visual Studio 2005는 ActiveSync를 통해 장치에 연결합니다.

이 문제를 해결하려면

TCP/IP를 통해 다른 장치에 연결하기 전에 ActiveSync를 통해 연결된 장치의 연결을 끊습니다.

3.8   자동화 기능으로 MFC dll을 배포하고 MFC 라이브러리에 동적으로 링크하면 0x8007007e 오류와 함께 dll을 등록하지 못합니다. 

자동화 기능으로 MFC dll 프로젝트를 배포하고 MFC 라이브러리에 동적으로 링크하는 동안 Visual Studio 2005에서는 dll과 필요한 종속 dll을 프로젝트 폴더 아래에 배포합니다. dll을 등록하는 데 사용하는 LoadLibrary()는 conman 구성 요소가 있는 디렉터리에서 종속 라이브러리를 찾은 다음 \Windows 디렉터리에서 찾습니다. 따라서 dll을 등록하지 못합니다.

이 문제를 해결하려면

필요한 종속 dll을 프로젝트 폴더에서 장치의 \Windows 디렉터리로 이동하거나 복사합니다.

3.9   임대 기간이 짧은 DHCP 서버의 무선 네트워크를 사용할 때 장치 에뮬레이터의 연결이 불안정합니다. 

무선 네트워크에서 가상 스위치 드라이버를 통해 장치 에뮬레이터에 TCP/IP를 연결하면 불안정할 수 있습니다. DHCP 서버 구현, 가상 스위치 드라이버 및 802.11 사양의 상호 작용에 따라 이러한 결과가 발생합니다.

이 문제를 해결하려면

장치 에뮬레이터에 안정적으로 연결하려면 다음 전송 방법 중 하나를 사용합니다.
1. DMA 전송

-또는-
2. 루프백 어댑터를 통한 TCP/IP 전송

3.10   MUI: 지역화된 원격 도구를 일치하지 않는 시스템 로캘에서 실행할 경우 장치 에뮬레이터에 연결할 수 없습니다. 

Visual Studio 2005의 지역화된 버전(예: 한국어)이 영어 버전의 MUI 운영 체제에 설치되어 있는 경우 원격 도구를 장치 에뮬레이터에 연결할 수 없습니다. 원격 도구는 항상 시스템 로캘을 사용하기 때문입니다. 같은 이유로, Visual Studio 2005의 서로 다른 로캘 두 가지(예: 한국어와 영어)가 영어 버전의 MUI 운영 체제에 설치된 경우 원격 도구는 항상 영어 버전의 장치 에뮬레이터에 연결됩니다.

이 문제를 해결하려면

시스템 로캘을 Visual Studio 2005 로캘과 일치하도록 변경합니다.

3.11   SmartDevice VC++ 응용 프로그램의 기본 프로젝트 설정이 /Os 컴파일러 옵션으로 설정되어 있어서 디버깅이 잘못되는 경우가 있습니다. 

SmartDevice VC++ 프로젝트의 기본 프로젝트 설정이 컴파일러 최적화 옵션 /Os로 설정되어 있습니다. /Os(코드 크기 우선)는 속도보다 크기를 우선적으로 처리하도록 컴파일러에 지시하여 실행 파일과 DLL의 크기를 최소화합니다. 이 설정으로 생성된 코드 때문에 디버깅이 잘못되는 경우가 있을 수 있습니다. 예를 들어, 코드를 단계별로 실행하는 동안 디버거가 if 및 else 문에 동시에 진입할 수 있습니다.

이 문제를 해결하려면

컴파일러 최적화 설정 "크기 또는 속도"를 /Os에서 모두 안 함으로 수정합니다.
단계
1) 프로젝트의 속성 페이지 대화 상자를 엽니다.
2) C/C++ 폴더를 클릭합니다.
3) 최적화 속성 페이지를 클릭합니다.
4) "크기 또는 속도" 속성을 모두 안 함으로 수정합니다.

이렇게 설정하면 디버깅이 더 잘됩니다. 하지만 실행 파일의 크기가 조금 늘어납니다.

3.12   지역화를 위해 표시된 폼이 포함된 Compact Framework 1.0 응용 프로그램을 컴파일할 때 빌드 오류가 발생합니다. 

지역화해야 하는 응용 프로그램을 개발하거나 Compact Framework 버전 1.0을 대상으로 하는 경우 SDK가 없다는 오류 메시지가 표시됩니다.

메시지:
"NET Compact Framework 1.0을 대상으로 하는 프로젝트를 지역화하는 데 필요한 .NET Framework SDK 버전 1.1을 컴퓨터에서 찾을 수 없습니다."

이 문제를 해결하려면

.NET Framework SDK 버전 1.1은 Visual Studio 2005 제품과 함께 제공되지 않습니다. SDK를 다운로드하여 설치해야 합니다.

다음 페이지에서 SDK를 다운로드하십시오.
http://www.microsoft.com/korea/msdn/netframework/downloads/updates/default.aspx

3.13   SqlCEResultSet DataSource를 끌어서 놓으면 디자이너 코드 파일에 컨트롤의 코드가 생성되지 않습니다. 

DataSource 창에서 SqlCEResultSet DataSource를 끌어서 장치 창 폼 디자이너에 놓으면 디자이너 코드 파일(예: Form1.designer.cs)에 컨트롤의 코드가 생성되지 않습니다.
이 문제는 다음과 같이 발생합니다.
1. 컨트롤 생성 옵션이 DataGrid로 설정된 경우: 디자이너 코드 파일에 DataGrid를 만들고 초기화하는 코드가 생성되지 않습니다.
2. 컨트롤 생성 옵션이 Details로 설정된 경우: 디자이너 코드 파일에 자세히 보기의 컨트롤을 만들고 초기화하는 코드가 생성되지 않습니다.

이 문제를 해결하려면

다음 단계 중 하나를 수행하면 됩니다.
1. 끌어서 놓기 전에 디자인 화면의 상황에 맞는 메뉴나 속성 창에서 폼의 속성을 편집합니다.
예를 들어, 디자인 화면에서 마우스 오른쪽 단추를 클릭하고 스킨 표시 설정을 해제합니다. 다시 스킨 표시를 설정합니다.

-또는-
2. 끌어서 놓기 전에 도구 상자의 폼에 컨트롤을 추가합니다.

-또는-
3. 끌어서 놓은 후에 디자인 화면의 상황에 맞는 메뉴나 속성 창에서 폼의 속성을 편집합니다.

-또는-
4. 끌어서 놓은 후에 도구 상자의 폼에 컨트롤을 추가합니다.

3.14   MFC 라이브러리에 동적으로 링크된 MFC ActiveX 컨트롤을 배포하면 0x8007007e 오류와 함께 컨트롤이 등록되지 않습니다. 

ActiveX 컨트롤을 등록하는 데 사용하는 LoadLibrary() API가 conman 구성 요소가 있는 디렉터리에서 종속 라이브러리를 찾은 다음 \Windows 디렉터리에서 찾습니다. 따라서 ActiveX 컨트롤이 등록되지 않습니다.

이 문제를 해결하려면

필요한 MFC dll을 장치의 \Windows 디렉터리에 복사합니다. 예를 들어, Visual Studio 2005가 C: 드라이브에 설치되어 있으면 armv4 프로세서의 MFC dll은 C:\Program Files\Microsoft Visual Studio 8\VC\ce\Dll\armv4에 있습니다.

3.15   장치 프로젝트의 정적 텍스트 컨트롤 하나 이상이 런타임에 표시되지 않습니다. 

스마트 장치에서 대화 상자 기반 MFC 응용 프로그램을 실행하면 장치의 정적 텍스트 컨트롤 중 하나가 런타임에 표시되지 않습니다. 원인은 다음 중 하나입니다.

1. 스마트 장치의 MFC 기반 대화 상자 응용 프로그램과 대화 상자를 만들기 위해 마법사에서 생성한 코드를 사용하면 개발자가 추가한 정적 텍스트 컨트롤이 두 개 이상 포함됩니다.
-또는-
2. 스마트 장치를 대상으로 하는 VC++ 응용 프로그램의 사용자 지정 개발 코드에 "확인 인식" 기능이 포함됩니다.

이 문제를 해결하려면

스마트 장치를 대상으로 하는 대화 상자 기반 MFC 응용 프로그램에 마법사에서 생성한 코드를 사용하면 기본적으로 마법사에서 "확인 인식" 응용 프로그램의 코드를 생성합니다. 확인 인식 응용 프로그램은 DRA(장치 확인 인식) API를 사용합니다. 생성된 코드는 가로 및 세로 모드를 지원하기 위해 API DRA::RelayoutDialog()를 호출합니다.

API DRA::RelayoutDilog()를 사용하려면 각 정적 텍스트 컨트롤에 고유한 ID를 사용해야 합니다. 하지만 기본적으로 개발자가 정적 텍스트 컨트롤을 끌어서 놓아 폼에 추가할 때 정적 텍스트 컨트롤의 모든 ID는 IDC_STATIC으로 생성됩니다.

모든 컨트롤을 런타임에 표시하려면 이러한 정적 텍스트 컨트롤의 ID를 IDC_STATIC_1, IDC_STATIC_2, IDC_STATIC_3 등으로 수정하여 고유한 ID를 만들어야 합니다. 이렇게 설정하면 "확인 인식" 응용 프로그램의 모든 정적 텍스트 컨트롤이 런타임에 표시됩니다.

정적 텍스트 컨트롤의 ID를 변경하려면 다음을 수행합니다.

1. 폼에서 컨트롤을 선택합니다.
2. 오른쪽 마우스 단추를 클릭하고 속성을 선택합니다.
3. "ID" 속성을 선택합니다.
4. 모든 정적 텍스트 컨트롤에서 IDC_STATIC을 IDC_STATIC_2,IDC_STATIC_3 등의 고유한 식별자로 변경합니다.

DRA::RelayoutDialog()에 대한 자세한 내용은 다음 페이지를 참조하십시오.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnppcgen/html/screen_orientation_awareness.asp (영문)

3.16   특정 장치에서 실행 중인 스마트 장치 Winsock 서버에서 OnConnect 콜백 알림을 받습니다. 

스마트 장치 소켓 서버 구현에는 WinCE를 대상으로 하는 CSocket 또는 CAsyncSocket을 사용하여 구현된 OnConnect() 및 OnAccept() 메서드가 포함됩니다. 클라이언트에서 장치에 호스팅된 이 서버에 연결하면 서버에서 OnAccept() 및 OnConnect() 알림을 받습니다.

이 문제를 해결하려면

서버에서 OnConnect() 알림을 받지 않으려면 다음을 수행합니다.

서버 소켓에서 Accept()를 호출하기 전에

1. 서버 소켓이 등록된 이벤트를 사용하여 AsyncSelect 메서드를 호출합니다. 즉, "소켓"이 서버 소켓의 개체이면
    socket.AsyncSelect(FD_READ | FD_WRITE | FD_OOB | FD_ACCEPT | FD_CLOSE)입니다.
서버에서 Connect 이벤트를 명시적으로 마스킹하기 위해 FD_CONNECT를 제외한 모든 이벤트가 사용됩니다.

2. 서버 소켓에서 다른 이벤트를 마스킹해야 할 경우 서버 소켓에서 작업할 특정 이벤트 목록을 사용합니다. 예를 들어, 서버 소켓에서 읽기 작업에 사용할 이벤트를 받지 않으려면 AsynchSelect 메서드를 다음과 같이 호출하여 이벤트 목록에서 FD_READ도 제거합니다. 

    socket.AsyncSelect(FD_WRITE | FD_OOB | FD_ACCEPT | FD_CLOSE);

ASyncSelect 메서드 동작에 대한 자세한 내용은 다음 페이지를 참조하십시오.
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_mfc_casyncsocket.3a3a.asyncselect.asp (영문)

3.17   .vcw 파일을 두 번 클릭하면 Visual Studio 2005에서 eVC4Project를 열 수 없습니다. 

개발자에게 eVC4를 사용하여 만든 장치 프로젝트가 있습니다.  Visual Studio 2005를 설치한 후에 Visual Studio 2005에서 eVC4 작업 영역 파일 "project.vcw"를 두 번 클릭하여 eVC4 프로젝트를 열려고 합니다.

이 문제를 해결하려면

표준 eVC4 프로젝트가 Visual Studio 2005 프로젝트로 등록되어 있지 않습니다.  eVC4 프로젝트를 Visual Studio 2005와 호환되는 솔루션 파일로 변환하려면 다음을 수행합니다.

1. Visual Studio 2005를 엽니다.
2. 파일 | 열기에서 프로젝트/솔루션을 클릭합니다.
3. 프로젝트 열기 대화 상자에서 vcw 파일로 이동하여 해당 파일을 선택한 다음 열기를 클릭합니다.
4. 예를 선택하고 이 프로젝트를 엽니다.

3.18   구문에 참조 형식이 포함되어 있는 경우 장치에서 구문을 마샬링하면 "NotSupportedException"이 반환됩니다.  

장치 프로젝트에서 아래 코드의 SizeOf 문은 NotSupportedException을 throw합니다.

Imports System.Runtime.InteropServices.MarShal
Module Module1
Structure S1
Public RefType As String
End Structure
Sub Main()
Dim sz As Integer
Dim struct As New S1
struct.RefType = "strings are reference types"
sz = SizeOf(struct)
End Sub
End Module

이 문제를 해결하려면

제대로 마샬링되도록 특성을 참조 형식에 적용합니다. 예를 들면 다음과 같습니다.
<MarshalAs(UnmanagedType.ByValTStr, SizeConst:=3)> Public x As String

자세한 내용은 ''MarshalAsAttribute''에 대한 설명서를 참조하십시오.

3.19   x86 또는 SH4 플랫폼에서 ''다른 이름으로 저장''을 선택하면 경로 선택 대화 상자가 표시되지 않습니다.
 

마법사에서 생성된 ''다른 이름으로 저장'' 옵션을 네이티브 MFC 프로젝트의 응용 프로그램 메뉴(파일 > 다른 이름으로 저장)에서 클릭하면 ''다른 이름으로 저장'' 대화 상자가 표시되지 않습니다.

이 문제를 해결하려면

공용 대화 상자 라이브러리에서 ''GetSaveFileName'' 함수를 사용합니다.
예를 들어, CWinApp 파생 클래스의 파일 이름을 만들려면 다음을 수행해야 합니다.

메시지 맵 항목을 만들고 ID_FILE_SAVE_AS 명령의 처리기를 등록합니다.
이렇게 하려면 다음과 같이 합니다.
- IDE 사용:
    1. ''다른 이름으로 저장'' 메뉴 항목을 마우스 오른쪽 단추로 클릭합니다. ''이벤트 처리기 추가'' 옵션을 선택합니다.
    2. 이름과 처리기에 대한 설명을 입력합니다. 처리기에 연결할 클래스를 선택합니다.
    3. 이제 ''추가 및 편집'' 옵션을 선택하여 적절할 항목을 만듭니다. 처리기에서 작성하는 데 필요한
    코드는 다음과 같습니다.

- 소스 파일 편집
    1. BEGIN_MESSAGE_MAP 매크로와 END_MESSAGE_MAP 매크로 사이에 ON_COMMAND(ID_FILE_SAVE_AS, your_handler) 형식의 항목을 추가합니다.
    2. 적절한 클래스에 사용할 헤더 파일에 처리기를 ''afx_msg void your_handler();''로 추가합니다.
    3. 아래 설명대로 소스에서 이 함수를 이 클래스에 대한 멤버 함수로 구현합니다.

- 처리기의 코드는 다음 단계를 수행해야 합니다.
    1. OPENFILENAME 구문을 선언하고 적절한 필드를 초기화합니다. OPENFILENAME에 대한 설명서를 참조하십시오.
    2. 이와 함께 이 구문에 대한 참조로 GetSaveFileName 함수를 호출합니다.
     이렇게 하면 파일 이름 선택 대화 상자가 표시됩니다.
    3. 구문의 ''lpstrFile'' 필드에 경로 선택 대화 상자에서 선택한 파일 이름이 포함됩니다.

- 처리기에서 이 파일 이름을 나중에 사용할 수 있습니다.

3.20   네이티브 디버깅에서 x86의 클래스 생성자에 대해 F11 키가 작동하지 않습니다.  

CEPC x86 장치를 대상으로 하는 경우 네이티브 디버깅에서 생성자 호출을 한 단계씩 실행할 수 없습니다.

예제:
class Foo
{
private:
int i;
public:
Foo()
{
    i = 0;
}    
};

int _tmain(int argc, _TCHAR* argv[])
{
    Foo *f = new Foo(); // 이 문에서 F11 키는 생성자를 한 단계씩 실행해야 하는데 "사용할 수 있는 소스가 없습니다. 디스어셈블리를 표시하겠습니까?"라는 창이 표시됩니다.
    return 0;
}

이 문제는 x86 아키텍처에만 적용됩니다.

이 문제를 해결하려면

중단점을 생성자에 직접 설정한 다음 F5 키를 누릅니다.  생성자의 코드는 x86 장치에서 디버깅되어야 합니다.

3.21   wceload.exe가 없는 에뮬레이터 또는 장치에 CAB 파일을 배포하는 동안 오류 메시지가 표시됩니다. 

wceload.exe는 Pocket PC와 Smartphone에서 .cab 파일의 설치 작업을 수행합니다.
wceload.exe 없이 .cab 파일을 장치 또는 에뮬레이터에 배포하면 "지정한 파일을 찾을 수 없습니다."라는 오류 메시지가 표시됩니다.

이 문제를 해결하려면

일치하는 wceload.exe를 장치의 \Windows 디렉터리에 직접 복사합니다.

3.22   가상 스위치 드라이버를 통해 TCP 전송을 사용하여 장치 에뮬레이터에 응용 프로그램을 배포하거나 디버깅하는 동안 연결이 간헐적으로 끊어집니다.  

이 문제는 가상 스위치 드라이버에 문제가 있기 때문에 발생합니다.

이 문제를 해결하려면

장치 에뮬레이터에 안정적으로 연결하려면 DMA 전송을 사용합니다.

3.23   여러 프로세스 사이에서 단계별로 실행할 수 없습니다. 

재현 단계:
1. VC++ -> 스마트 장치 -> Win32 스마트 장치 프로젝트를 만듭니다.
2. 프로젝트 만들기 마법사에서 PPC 2003 SDK와 Windows 응용 프로그램 형식을 선택합니다.
3. 프로젝트를 빌드합니다.
4. WndProc의 마지막 문(return 0;)에 중단점을 설정합니다.
5. F5 키를 누릅니다.
6. 중단점에 도달하면 호출 스택을 확인합니다.
7. F10 키를 두 번 눌러 함수에서 나옵니다.
8. WndProc에서 나가면 호출자가 다른 프로세스에 있기 때문에 "단계별로 실행할 수 없습니다." 오류가 반환됩니다.

이 문제를 해결하려면

여러 프로세스 사이에서 단계별로 실행하는 것은 지원되지 않습니다. 사용자는 마지막 줄에서 F10 키 대신 F5 키를 눌러 디버거를 실행하여 이 오류를 방지할 수 있습니다.

3.24   생성된 데이터 폼의 EditViewDialog에 있는 ComboBox 컨트롤에서 잘못된 LookUpBinding 동작이 나타납니다. 

생성된 데이터 폼의 EditViewDialog에 있는 ComboBox 컨트롤에서 잘못된 LookUpBinding 동작이 나타납니다.

예를 들어, 다음 단계를 수행할 때 이 동작이 나타날 수 있습니다.
1. PPC Magneto 장치 VB 프로젝트를 만듭니다.
2. 서버 탐색기에서 Northwind SDF 데이터베이스에 대한 연결을 만듭니다.
3. 데이터 소스 창에서 Northwind SDF 데이터베이스의 모든 테이블이 포함된 데이터 소스를 만듭니다.
4. Orders 테이블을 데이터 표로 끌어다 놓습니다.
5. 데이터 소스 창에서 Orders.[Customer ID]의 컨트롤 형식을 comboBox로 변경합니다.
6. DataGrid 스마트 작업을 사용하여 Orders에 대한 데이터 폼을 생성합니다.
7. Form1.vb 코드 파일에서 다음 줄을
   "OrdersTableAdapter.Update(Me.NorthwindDataSet.Orders)"
   다음 함수의 마지막 문으로 추가합니다.
   - NewMenuItemMenuItem_Click
   - OrdersDataGrid_Click
8. EditViewDialog 폼을 엽니다.
9. Customer_IDComboBox 속성을 편집하여 다음을 설정합니다.
   DataSource 값: CustomersBindingSource
   ValueMember 값 - 고객 ID
   DisplayMember 값 - 회사 이름
   데이터 바인딩 값::선택한 값: OrdersBindingSource - 고객 ID
10. 빌드하여 에뮬레이터에 배포합니다.
11. 에뮬레이터에서 레코드를 클릭하여 주문의 SummaryView를 표시합니다.
12. 편집을 클릭하여 주문의 EditView를 표시합니다.

예상 결과:
   comboBox에는 선택한 주문의 고객 ID에 해당하는 회사 이름이 표시되어야 합니다.

실제 결과:
- comboBox에 회사 이름 목록에 있는 첫 번째 회사 이름이 표시됩니다.
- 확인을 클릭하면 첫 번째 회사 이름에 해당하는 고객 ID로 주문이 수정됩니다.

이 문제를 해결하려면

OrdersEditViewDialog 생성자 안에서 InitializeComponent 함수 호출 바로 뒤에 OrdersEditViewDialog_Load 함수의 내용을 잘라서 붙여 넣습니다.

4. 소스 코드 제어 통합

4.1   FrontPage 소스 제어 컨트롤에서 폴더의 이름을 바꾸면 해당 폴더 아래에 있는 파일을 제어할 수 없게 됩니다. 

FrontPage 버전 관리 제어를 사용하는 원격 웹 사이트에서 작업하면서 폴더 이름을 소스 제어 항목 내부로 바꾸면 웹 사이트를 닫았다가 다시 열 때까지 해당 폴더의 모든 항목이 제어할 수 없는 것으로 표시됩니다.

이 문제를 해결하려면

폴더의 이름을 바꾼 후에는 웹 사이트를 닫았다가 다시 엽니다.

4.2   다양한 수준의 IIS 웹이 포함된 소스 제어에서 솔루션을 열 경우, 디버깅하려면 웹의 부모 폴더에 IIS의 읽기 권한을 추가해야 합니다. 

IIS 웹 사이트가 포함된 소스 제어에서 솔루션을 열면 VS는 URL의 대상 경로에만 IIS 읽기 권한을 부여합니다. 하지만 IIS 웹 사이트를 디버깅하려면 IIS에는 URL의 가상 경로에 각 폴더에 대한 읽기 권한이 있어야 합니다. 따라서 두 수준 이상의 웹 사이트가 포함된 솔루션을 열 경우(예: http://localhost/MyWebs/Web1) 웹 사이트를 디버깅하려면 부모 웹(예: http://localhost/MyWebs)에서 가리키는 폴더에 상관없이 IIS에 읽기 권한을 부여해야 할 수도 있습니다.

이 문제를 해결하려면

Windows 탐색기에서 URL의 부모 폴더에 ASP.NET 사용자 계정에 대한 "읽기" 권한을 추가합니다. Windows Server 2003을 사용할 경우에는 NETWORK SERVICE 계정에 폴더를 읽을 수 있는 권한도 필요합니다. 예를 들어, 소스 제어에서 "http://localhost/MyWebs/Web1"이 포함된 솔루션을 열 경우 Windows 탐색기에서 "http://localhost/MyWebs"가 가리키는 디렉터리로 이동하여 이 폴더에 권한을 추가합니다. 또는 Users 그룹에 읽기 권한이 있을 경우 컴퓨터의 다른 위치에 솔루션을 열도록 선택할 수 있습니다. 기본적으로 내 문서 디렉터리와 그 하위 디렉터리의 읽기 권한은 Users 그룹에 부여되지 않습니다.

5. Crystal Reports

Crystal Reports for Visual Studio 2005에 대한 자세한 내용은 http://www.businessobjects.com/products/reporting/crystalreports/net/vsnet.asp (영문)를 참조하십시오.

6. Tools for the Microsoft Office System

6.1   Visual Studio Tools for Office에서 multipart XML 스키마를 지원하지 않습니다. 

Visual Studio Tools for Office는 주 스키마 하나를 기반으로 하는 XmlMap만 지원합니다. Microsoft Office Excel에서 주 스키마 하나와 선택적 보조 스키마로 구성된 XmlMap을 지원하더라도 이는 마찬가지입니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

6.2   WordDynamicControls 샘플을 다시 열 때 컨트롤이 로드되지 않습니다. 

WordDynamicControls 샘플을 사용할 때 컨트롤을 추가한 다음 문서를 닫고 다시 열어 확인해 보면 앞서 추가한 컨트롤이 저장되어 있지 않은 경우가 있습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

6.3   디자이너에서 통합 문서를 열면 VBA 코드 및 XLM(Excel 4.0 매크로) 코드가 실행됩니다.  

통합 문서 이벤트 처리기에 VBA(Visual Basic for Applications) 또는 XML(Excel 4.0 매크로) 코드가 있는 경우 디자이너에 통합 문서가 열려 있으면 이 코드가 실행됩니다.

이 문제를 해결하려면

Visual Studio Tools for Office를 사용하여 통합 문서를 사용자 지정할 때 VBA 또는 XLM 코드가 실행되지 않도록 하려면 통합 문서를 기반으로 프로젝트를 만들기 전에 통합 문서와 연결된 VBA 또는 XML 코드를 모두 제거해야 합니다.

6.4   Microsoft Office XP만 설치되어 있는 컴퓨터에 Visual Studio Team System을 설치하면 Word 또는 Excel을 시작할 때 보안 대화 상자가 열립니다. 

Office XP만 설치되어 있는 컴퓨터에 Visual Studio Team System을 설치한 다음 Word 또는 Excel을 시작하면 다음과 같은 Office 보안 대화 상자가 나타납니다.

VSTOWordAdaptor.dll [또는 VSTOExcelAdaptor.dll]
다음 사용자가 만든 매크로가 포함되어 있습니다.
Microsoft Coporation

매크로가 바이러스에 감염되었을 수 있습니다. 매크로를 제외하고 문서를 여는 것이 안전합니다. 그러나 이 경우 매크로가 동작하지 않으므로 해당 기능을 사용할 수 없습니다.

보안 수준이 높음으로 설정되어 있습니다. 신뢰하지 않는 원본의 매크로를 사용할 수 없습니다.
[] 이 원본의 매크로는 항상 신뢰

[매크로 제외] [매크로 포함] [추가 정보]

이 경고는 VSTOWordAdaptor.dll 및 VSTOExcelAdaptor.dll에 서명하는 데 사용된 Microsoft 서명이 Office XP의 신뢰할 수 있는 서명 목록에 없기 때문에 표시됩니다. Office 2003의 신뢰할 수 있는 서명 목록에는 Microsoft 서명이 있습니다.

이 문제를 해결하려면

Microsoft Corporation의 매크로를 신뢰하도록 설정합니다. Visual Studio 2005 Tools for Office를 사용하려면 지원되는 버전의 Office 2003을 설치해야 합니다. Office 2003을 설치하면 이 Microsoft 서명이 신뢰할 수 있는 서명 목록에 추가됩니다.

6.5   바인딩된 항목이 있는 테이블을 데이터 집합에서 제거하면 응용 프로그램을 디버깅할 때 구성 요소 트레이에서 구성 요소가 제거될 수 있습니다. 

이 문제는 목록 개체 같은 데이터 바인딩된 호스트 컨트롤을 디자인 화면에서 제거한 다음 이 컨트롤이 바인딩되어 있던 테이블을 편집 기능이나 데이터 소스 구성 마법사를 사용하여 데이터 소스에서 제거할 때 발생합니다. 이 상태에서 새 호스트 컨트롤을 추가하고 응용 프로그램을 디버깅하면 예외가 발생할 수 있습니다. 디버깅을 중지하면 디자인 화면이 언로드되고 데이터 구성 요소가 구성 요소 트레이에서 제거됩니다.

이 문제를 해결하려면

디자인 화면에서 호스트 컨트롤을 제거한 다음 이 컨트롤이 바인딩되어 있던 테이블을 데이터 소스에서 제거할 때는 응용 프로그램을 빌드하기 전에 반드시 테이블의 바인딩 소스를 수동으로 제거해야 합니다.

6.6   Windows 사용자 로캘을 영어가 아닌 다른 언어로 설정하면 Windows Forms 컨트롤 extender 속성이 영어 버전의 Excel에 표시되지 않습니다. 

이 문제는 영어가 아닌 다른 언어로 Windows 사용자 로캘이 변경된 경우 영어 버전의 Excel에서 발생합니다. 높이와 너비 같은 일부 속성을 Excel 디자인 화면에 호스팅된 Windows Forms 컨트롤에 사용할 수 없습니다.

이 문제를 해결하려면

Office MUI(다국어 사용자 인터페이스) 팩을 시스템에 설치합니다. Excel 사용자 인터페이스 언어는 변경하지 않아도 됩니다.

6.7   Windows 탐색기에서 "같은 창에서 열기"를 선택하지 않고 HTTP를 통해 문서를 열면 Word에서 Visual Studio Tools for Office 사용자 지정 정보가 로드되지 않습니다. 

"같은 창에서 열기" 속성은 Internet Explorer에서 문서를 브라우저 안에 호스팅할지 별도의 창에 호스팅할지 결정하는 데 사용됩니다. 문서를 별도의 창에 호스팅하는 경우에는 사용자 지정 정보를 로드하여 실행할 수 없습니다.

이 문제를 해결하려면

Windows 탐색기에서 "같은 창에서 열기"를 선택합니다.
"같은 창에서 열기" 속성을 찾으려면
1) Windows 탐색기를 엽니다.
2) 도구 메뉴를 클릭합니다.
3) 폴더 옵션을 클릭합니다.
4) 파일 형식 탭을 클릭합니다.
5) 등록된 파일 형식 목록에서 DOC를 선택합니다.
6) 고급을 클릭합니다.

6.8   Visual Studio Tools for Office 문서를 체크 아웃할 때 관련 필수 파일이 소스 코드 컨트롤에서 체크 아웃되지 않습니다. 

소스 코드 컨트롤에서 Visual Studio Tools for Office 문서를 체크 아웃할 때 필수 파일 중 일부가 자동으로 체크 아웃되지 않습니다. 이 문제는 생성된 코드가 문서의 데이터 구성 요소 속성 및 UI(사용자 인터페이스) 컨트롤과는 다른 별도의 파일에 저장되기 때문에 발생합니다.

종속 파일은 체크 아웃되지 않아 업데이트할 수 없기 때문에 문서를 체크 인하면 종속 파일에 대해 간접적으로 수행했던 변경 사항이 손실됩니다.

서버에 관련 파일의 최신 버전이 있지만 문서만 체크 아웃한 경우 최신 속성은 표시되지 않습니다. 서버에 있는 관련 파일을 문서와 함께 체크 인하면 이 관련 파일의 속성을 덮어쓰게 됩니다.

이 문제를 해결하려면

체크 인한 문서를 수정하기 전에 먼저 모든 관련 파일을 체크 아웃합니다. 문서를 체크 인할 때는 모든 관련 파일을 체크 인해야 합니다. 이러한 파일은 "모든 파일 표시"를 선택한 경우 솔루션 탐색기에서 문서 아래 들여쓴 형식으로 표시됩니다.

6.9   Word 템플릿이 인쇄 레이아웃 보기가 아닌 기본 보기로 열리기 때문에 인라인이 아닌 컨트롤이 표시되지 않습니다. 

Word에서 텍스트와 같은 줄에 있지 않은 개체는 인쇄 레이아웃 보기에서만 표시됩니다. 기본적으로 Visual Studio Tools for Office 문서에 추가되는 UI 컨트롤은 텍스트와 같은 줄에 배치됩니다. 컨트롤을 마우스 오른쪽 단추로 클릭하고 "컨트롤 서식..."을 클릭한 다음 "레이아웃"을 클릭하여 레이아웃 형식을 변경할 수 있습니다.

기본적으로 Visual Studio Tools for Office는 Word 템플릿을 기본 보기로 열기 때문에 인라인이 아닌 컨트롤은 표시되지 않습니다.

이 문제를 해결하려면

기본 보기에서 인쇄 레이아웃 보기로 전환하여 컨트롤을 표시합니다.

6.10   디자인 타임에 비활성 Excel 시트에서 컨트롤을 삭제해도 자동 생성된 코드가 남을 수 있습니다. 

각 워크시트에는 필요 시 로드되는 고유한 디자인 화면이 있습니다. 예를 들어, 컨트롤을 추가, 삭제 또는 변경할 때처럼 워크시트가 변경되는 경우에는 디자인 화면에서 이러한 변경이 감지되어 생성된 코드가 업데이트됩니다.
그러나 디자인 타임에 비활성 시트에서 컨트롤을 삭제하면 디자인 화면이 인스턴스화되지 않은 상태이므로 생성된 코드가 부분적으로만 업데이트됩니다. 이 문제의 발생 원인에는 대체로 두 가지가 있습니다. 우선, "명명된 범위 관리" 대화 상자를 사용하여 비활성 시트에서 NamedRange 컨트롤을 삭제하는 경우가 여기에 해당합니다. 또는 Visual Studio 외부에서 Excel 문서를 열고 컨트롤을 제거한 다음 Visual Studio 안에서 문서를 다시 여는 경우에도 이 문제가 발생합니다.

이 문제를 해결하려면

"명명된 범위 관리" 대화 상자를 사용하여 NamedRange 컨트롤을 삭제하기 전에 워크시트를 활성화합니다.
빌드 오류를 해결하려면 속성을 편집하거나, 컨트롤을 화면에 추가하거나, 화면에서 컨트롤을 삭제하여 문제가 발생한 각 시트를 변경된 것으로 표시합니다. 그런 다음 프로젝트를 다시 빌드합니다.

6.11   Visual Studio Tools for Office가 64비트 응용 프로그램을 기본적으로 지원하지 않습니다. 

기본적으로 Visual Studio Tools for Office 및 기타 프로젝트 형식은 "Any CPU" 형식으로 생성됩니다. 그러나 Visual Studio Tools for Office 솔루션은 32비트 환경에서만 작동합니다.

이 문제를 해결하려면

64비트 컴퓨터에서 Visual Studio Tools for Office 솔루션을 실행하려면 프로젝트 속성에서 대상 플랫폼을 "Any CPU"가 아닌 x86으로 변경해야 합니다. 이는 응용 프로그램을 64비트 Windows 운영 체제에 배포하는 경우라 해도 마찬가지입니다. ServerDocument 클래스를 사용하는 다른 형식의 응용 프로그램(예: 콘솔 또는 Windows Forms 응용 프로그램)에 대해서도 이와 같이 변경해야 합니다.

6.12   Visual Studio Tools for Office 프로젝트에서 Visual Studio Team System 단위 테스트를 지원하지 않습니다. 

Visual Studio Team System 제품에서 제공하는 단위 테스트 기능은 Visual Studio Tools for Office에서 지원되지 않습니다.

이 문제를 해결하려면

알려진 해결 방법이 없습니다.

6.13   Microsoft Office 응용 프로그램의 디버깅 종료 시, 잘못된 "프로세스 종료" 대화 상자가 나타납니다. 

Microsoft Office 응용 프로그램을 디버깅할 때, [디버깅 중지] 메뉴 또는 버튼을 누르면,데이터가 손실되거나 시스템이 불안정해 질 수 있다는 잘못된 프로세스 종료 경고 대화 상자가 나타납니다. 이 대화 상자는 무시하십시오.

이 문제를 해결하려면

단순히 [예] 버튼을 누르면 정상적으로 디버깅이 중지됩니다