Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 4개 있습니다.)

OpenAuth 사용 시 System.Data.SqlClient.SqlException 예외가 Output 창에 출력되는 문제

가령 OpenAuth를 사용하는 웹 프로젝트를 F5 디버깅으로 Visual Studio에서 실행시키면 OpenAuth.Login 메서드를 호출하는 시점에,

bool loggedIn = OpenAuth.Login(authResult.Provider, authResult.ProviderUserId, createPersistentCookie: true);

출력창을 보면 다음과 같은 예외가 우수수 떨어지는 것을 볼 수 있습니다.

The thread 0x5cb8 has exited with code 259 (0x103).
The thread 0x5f80 has exited with code 259 (0x103).
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in EntityFramework.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in EntityFramework.SqlServer.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in System.Data.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in EntityFramework.dll
A first chance exception of type 'System.Data.SqlClient.SqlException' occurred in EntityFramework.SqlServer.dll

System.Data.SqlClient.SqlException의 원인은 IntelliTrace 옵션을 켜고 다시 실행해 보면 IntelliTrace 뷰에 다음과 같은 예외로 좀 더 추측해 볼 수 있습니다.

Exception:Thrown: "There is already an object named 'UsersOpenAuthAccounts' in the database." (System.Data.SqlClient.SqlException) A System.Data.SqlClient.SqlException was thrown: "There is already an object named 'UsersOpenAuthAccounts' in the database."


UsersOpenAuthAccounts는 OpenAuth에서 생성한 Database에 있는 테이블 이름입니다. 그런데 그 테이블을 다시 생성하려고 했다는 듯 싶은데요. 이제 소스코드 레벨로 내려가서 원인을 추적해봐야 할 차례가 된 것 같습니다. 이럴 때 .NET Reflector의 "Generate PDBs" 기능을 이용해 소스코드 디버깅의 도움을 받을 수 있습니다.

그리하여 추적해 보면 Microsoft.AspNet.Membership.OpenAuth.EFOpenAuthMembershipDatabase 타입의 GetContext 메서드에서 발생하는 것을 볼 수 있습니다.

// Microsoft.AspNet.Membership.OpenAuth.dll

private OpenAuthDbContext GetContext()
{
    if (!_dbInitialized) // _dbInitialized == false
    {
        DatabaseInitialize();
    }
    OpenAuthDbContext db = new OpenAuthDbContext(this._connectionString);
    if (!_dbCreated)
    {
        _dbCreated = true; // _dbInitialized == false
        EnsureDatabaseCreated(db); // 이 시점에 출력 창에 예외 발생
    }
    return db;
}

즉, EFOpenAuthMembershipDatabase 타입은 응용 프로그램에서 최초 호출하는 시점에 EntityFramework의 DbContext를 상속받은 OpenAuthDbContext를 무조건 초기화하도록 만들어져 있기 때문입니다.

다행인 것은, EFOpenAuthMembershipDatabase는 최초 생성 시점에만 그런 동작을 할 뿐 이후로는 _dbInitialized == true, _dbInitialized == true로 설정된 타입을 갖는 동적 어셈블리(EntityFrameworkDynamicProxies-Microsoft.AspNet.Membership.OpenAuth)를 생성해 호출하므로 이로 인한 응용 프로그램의 부하는 없습니다.

이 외에도 System.Web.Providers.MembershipContext 타입에서도 초기화를 하기 때문에,

// System.Web.Providers.dll

internal static MembershipContext CreateMembershipContext(ConnectionStringSettings setting)
{
    if (!DbInitialized)
    {
        DatabaseInitialize();
    }
    MembershipContext db = new MembershipContext(setting.Name);
    if (!MembershipInitialized)
    {
        EnsureDatabaseCreated(db);
        ExecuteSql(db, "CREATE NONCLUSTERED INDEX IDX_UserName ON Users (UserName)"); // 이 시점에 출력 창에 예외 발생
        MembershipInitialized = true;
    }
    return db;
}

System.Data.SqlClient.SqlException 예외가 아래와 같은 항목으로 더 어지럽게 출력 창에 흩뿌려지게 됩니다.

Exception:Thrown: "There is already an object named 'Applications' in the database." (System.Data.SqlClient.SqlException) A System.Data.SqlClient.SqlException was thrown: "There is already an object named 'Applications' in the database."

Exception:Thrown: "The operation failed because an index or statistics with name 'IDX_UserName' already exists on table 'Users'." (System.Data.SqlClient.SqlException) A System.Data.SqlClient.SqlException was thrown: "The operation failed because an index or statistics with name 'IDX_UserName' already exists on table 'Users'."


결론적으로 보면, 이런 오류가 발생했다고 해서 별다르게 취할 조치는 없습니다. 의도된 것이므로 취할 필요도 없습니다.




개인적으로 "깨진 유리창" 이론이 프로그래밍의 버그 발생에도 적용된다고 생각합니다. 즉, 이번 글에서처럼 저런 식으로 어쩔 수 없이 예외가 발생해 출력 창을 어지럽히면 점점 더 해당 프로젝트는 'first-chance 예외'의 발생에 관대해지게 되고 결국에는 아무도 신경쓰지 않는 상황으로 바뀝니다.

문제는, 개발자들이 습관적으로 하는 try/catch로 인해 나중에 정말로 중요한 예외가 먹혔을때(좀 더 전문 용어로 씹혔을때!) 그 사실을 인지하지 못해 외관상 잘 동작하는 프로그램이 내부적으로는 잘 파악도 되지 않는 버그로 발전하게 되는 경우가 다분하다는 것입니다. 그럴 때 그 문제를 수정하기 위해 얼마나 많은 시간을 소비해야 하는지... 그리고 그로 인한 시간 소비가 버그를 해결했다는 정신적인 쾌감보다는 '이런 쓸데없는 것에...'라는 짜증이 더 많은 비중으로 차지한다는 것은 경험자만 알 수 있을 것입니다.

따라서, 저는 저렇게 출력 창에 내보내지는 예외를 가능한 없애려고 하는 주의를 고수합니다.

자... 그럼 어떻게 해야 할까요? 간단합니다. 해당 멤버들이 private static 필드이니 Global.Application_Start 같은 함수에서 Reflection을 이용해 true로 명시해 주면 됩니다. 단지, 릴리스 상황에서의 관리를 편하게 할 수 있도록 DEBUG 전처리기를 추가해 주면 좋을 것입니다. 이렇게!

#if DEBUG
    Type efdb = typeof(Microsoft.AspNet.Membership.OpenAuth.EFOpenAuthMembershipDatabase);
    FieldInfo fieldInfo = efdb.GetField("_dbCreated", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
    if (fieldInfo != null)
    {
        fieldInfo.SetValue(null, true);
    }

    Type mhdb = Assembly.GetAssembly(typeof(System.Web.Providers.DefaultMembershipProvider)).GetType("System.Web.Providers.ModelHelper");
    fieldInfo = mhdb.GetField("MembershipInitialized", System.Reflection.BindingFlags.Static | System.Reflection.BindingFlags.NonPublic);
    if (fieldInfo != null)
    {
        fieldInfo.SetValue(null, true);
    }
#endif

역시... 디버그 출력창은 조용해야 합니다. 한마디로, 개발자의 관리하에 놓여야 합니다.



반면, 아래와 같은 오류가 발생할 수 있습니다.
Server Error in '/' Application.

Cannot attach the file '...\App_Data\TestDB.mdf' as database 'TestDB'. 
  Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code. 

 Exception Details: System.Data.SqlClient.SqlException: Cannot attach the file '...\App_Data\TestDB.mdf' as database 'TestDB'.

원인은 간단합니다. TestDB를 지운 다음 DEBUG로 인해 DB 생성이 안되는 문제입니다. 따라서 이런 오류가 발생하면 다시 위의 리플렉션 코드를 주석처리해야 합니다. ^^




[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[연관 글]






[최초 등록일: ]
[최종 수정일: 2/19/2024]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12070정성태12/9/201915395오류 유형: 581. resize2fs: Bad magic number in super-block while trying to open /dev/.../root
12069정성태12/2/201911760디버깅 기술: 139. windbg - x64 덤프 분석 시 메서드의 인자 또는 로컬 변수의 값을 확인하는 방법
12068정성태11/28/201915105디버깅 기술: 138. windbg와 Win32 API로 알아보는 Windows Heap 정보 분석 [3]파일 다운로드2
12067정성태11/27/201911763디버깅 기술: 137. 실제 사례를 통해 Debug Diagnostics 도구가 생성한 닷넷 웹 응용 프로그램의 성능 장애 보고서 설명 [1]파일 다운로드1
12066정성태11/27/201911620디버깅 기술: 136. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석 - OracleCommand.ExecuteReader에서 OpsSql.Prepare2 PInvoke 호출 분석
12065정성태11/25/201910489디버깅 기술: 135. windbg - C# PInvoke 호출 시 마샬링을 담당하는 함수 분석파일 다운로드1
12064정성태11/25/201912678오류 유형: 580. HTTP Error 500.0/500.33 - ANCM In-Process Handler Load Failure
12063정성태11/21/201911702디버깅 기술: 134. windbg - RtlReportCriticalFailure로부터 parameters 정보 찾는 방법
12062정성태11/21/201911789디버깅 기술: 133. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례 - 두 번째 이야기
12061정성태11/20/201911957Windows: 167. CoTaskMemAlloc/CoTaskMemFree과 윈도우 Heap의 관계
12060정성태11/20/201912333디버깅 기술: 132. windbg/Visual Studio - HeapFree x64의 동작 분석
12059정성태11/20/201911933디버깅 기술: 131. windbg/Visual Studio - HeapFree x86의 동작 분석
12058정성태11/19/201912729디버깅 기술: 130. windbg - CoTaskMemFree/FreeCoTaskMem에서 발생한 덤프 분석 사례
12057정성태11/18/20199850오류 유형: 579. Visual Studio - Memory 창에서 유효한 주소 영역임에도 "Unable to evaluate the expression." 오류 출력
12056정성태11/18/201913690개발 환경 구성: 464. "Microsoft Visual Studio Installer Projects" 프로젝트로 EXE 서명 및 MSI 파일 서명 방법파일 다운로드1
12055정성태11/17/20199408개발 환경 구성: 463. Visual Studio의 Ctrl + Alt + M, 1 (Memory 1) 등의 단축키가 동작하지 않는 경우
12054정성태11/15/201910751.NET Framework: 869. C# - 일부러 GC Heap을 깨뜨려 GC 수행 시 비정상 종료시키는 예제
12053정성태11/15/201912438Windows: 166. 윈도우 10 - 명령행 창(cmd.exe) 속성에 (DotumChe, GulimChe, GungsuhChe 등의) 한글 폰트가 없는 경우
12052정성태11/15/201911542오류 유형: 578. Azure - 일정(schedule)에 등록한 runbook이 1년 후 실행이 안 되는 문제(Reason - The key used is expired.)
12051정성태11/14/201914008개발 환경 구성: 462. 시작하자마자 비정상 종료하는 프로세스의 메모리 덤프 - procdump [1]
12050정성태11/14/201911690Windows: 165. AcLayers의 API 후킹과 FaultTolerantHeap
12049정성태11/13/201911782.NET Framework: 868. (닷넷 프로세스를 대상으로) 디버거 방식이 아닌 CLR Profiler를 이용해 procdump.exe 기능 구현
12048정성태11/12/201912543Windows: 164. GUID 이름의 볼륨에 해당하는 파티션을 찾는 방법
12047정성태11/12/201914401Windows: 163. 안전하게 eject시킨 USB 장치를 물리적인 재연결 없이 다시 인식시키는 방법
12046정성태10/29/201910380오류 유형: 577. windbg - The call to LoadLibrary(...\sos.dll) failed, Win32 error 0n193
12045정성태10/27/20199721오류 유형: 576. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 - 두 번째 이야기
... 61  62  [63]  64  65  66  67  68  69  70  71  72  73  74  75  ...