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

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

이 문제를 해결하려면

long 대신 integer를 사용합니다.

4. Visual J# Express

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

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

이 문제를 해결하려면

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

5. Visual C++ Express

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

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

이 문제를 해결하려면

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

6. .NET Framework

6.1 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 쿼리 그룹이 잘못되었다는 것을 나타냅니다.

이 문제를 해결하려면

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

6.2 공유 호스팅 컴퓨터에서 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

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

6.5 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 또는 string의 serialization 중 하나)을 사용해야 합니다. 응용 프로그램 간에 임시 클래스 파일을 실수로 공유할 가능성이 높지 않은 응용 프로그램의 경우에는 작업자 프로세스 또는 응용 프로그램 가장 ID에 %windir%\temp 디렉터리에 대한 "폴더 보기/데이터 읽기" 권한을 부여할 수 있습니다.

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

6.8 시간 제한이 System.Net에서 확인을 수행하기 위해 호출한 관리되지 않는 API의 시간 제한보다 적을 때 System.Net에서 DNS 확인의 시간 제한을 설정하는 논리를 제거했습니다.

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

이 문제를 해결하려면

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

6.9 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에 사용할 명령을 실행할 때 사용할 연결 문자열과 동일해야 합니다.

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

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

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

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

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

이 문제를 해결하려면

HttpWebRequest.Address를 사용합니다.

6.15 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>

6.16 .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>

6.17 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를 사용합니다.

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

1. 트랜잭션에 대한 액세스가 동기화되었는지 확인합니다.
   -또는-
2. DistributedIdentifier 속성을 확인하기 전에 트랜잭션이 확장되었는지 확인합니다.

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

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

이 문제를 해결하려면

다음 두 가지 방법이 있습니다.

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

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

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

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

한 버전의 .NET Framework에서 실행되는 응용 프로그램과 다른 버전에서 실행되는 응용 프로그램 간에 .NET Remoting 또는 런타임 Serialization을 사용하여 데이터를 교환하면 특정 Framework 형식을 serialize 또는 deserialize하는 동안 예외가 발생할 수 있습니다. 이러한 예외는 해당 형식이 서로 다른 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에 있는 기술 자료 문서를 참조하십시오.

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

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

이 문제를 해결하려면

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

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

NET Framework 2.0은 XML에서 날짜 및 시간을 읽고 쓰는 방법을 변경합니다. 이러한 변경은 주로 다음과 같은 시나리오에 영향을 미칩니다.

- 표준 시간대를 지정하지 않은 시간 또는 UTC 표준 시간대 시간 사용
- 표준 시간대나 UTC 시간대를 지정하지 않고 시간 값을 XML에 기록하는 타사 소프트웨어와의 상호 운용성 시나리오

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

이 문제를 해결하려면

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

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

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

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

이 문제를 해결하려면

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

6.27 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는 서로게이트 문자만 포함하는 두 개의 사용자 이름을 동일한 것으로 간주합니다. 기존 사용자와 서로게이트 문자만 다른 사용자 이름으로 두 번째 사용자를 만들면 이 동작으로 인해 고유성 제약 조건 위반이 발생합니다.

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

6.30 NET Remoting 또는 이진 Serialization에 제네릭 형식을 사용할 때 경우에 따라 버전 관리 기능은 작동하지 않습니다

.NET Remoting 및 이진 Serialization은 모두 FormatterAssemblyStyle을 Simple로, includeVersions를 False로, strictBinding을 False로 설정하여 선택할 수 있는 느슨하게 연결된 모드에서만 작동합니다. 여기서 serialize된 형식의 어셈블리 버전은 형식이 deserialize 시 로드되는 어셈블리 버전과 일치하지 않아도 됩니다. 이 기능은 버전 관리를 손쉽게 할 수 있도록 하기 위해 제공합니다. 예를 들어, 클라이언트를 업데이트하지 않고도 .NET Remoting 서버를 업데이트할 수 있습니다.

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

이 문제를 해결하려면

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

7. MSDN Express

현재로서는 알려진 문제가 없습니다.

8. Visual Studio 통합 개발 환경

현재로서는 알려진 문제가 없습니다.

9. Visual Web Developer Express

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

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

다음은 이 경고가 표시되는 일반적인 프로젝트 구성의 예입니다.

웹 디렉터리에 global.asax 파일이 포함되고 App_Code 디렉터리에 global.asax.cs 파일이 포함된 이전 버전의 Visual Studio에서 마이그레이션된 웹 프로젝트

웹 페이지에서 웹 사용자 정의 컨트롤을 참조하고 웹 사용자 정의 컨트롤은 App_Code 디렉터리에 선언된 형식을 참조하는 웹 프로젝트

이 문제를 해결하려면

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

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

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

바로 가기 문자열 안에는 많은 유니코드 문자를 사용할 수 있지만 간격 없음 표시는 사용할 수 없습니다. 즉, 일부 언어의 일부 문자열은 바로 가기로 사용할 수 없습니다. 바로 가기가 간격 없음 표시를 포함하는 경우 바로 가기 문자열을 입력하고 Tab 키를 누르면 탭 문자가 삽입되며 코드 조각은 삽입하지 않습니다.

이 문제를 해결하려면

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

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

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

다음은 이 경고가 표시되는 일반적인 프로젝트 구성의 예입니다.

웹 디렉터리에 global.asax 파일이 포함되고 App_Code 디렉터리에 global.asax.cs 파일이 포함된 이전 버전의 Visual Studio에서 마이그레이션된 웹 프로젝트

웹 페이지에서 웹 사용자 정의 컨트롤을 참조하고 웹 사용자 정의 컨트롤은 App_Code 디렉터리에 선언된 형식을 참조하는 웹 프로젝트

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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

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

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

이 문제를 해결하려면

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