Honsal's Dailylife

JetBrains Rider 2023.2.3에서 NUnit 4 지원 안 됨 NUnit 4 2023년 11월 26일에 NUnit 4.0.0이 릴리즈되고 바로 이틀 전인 12월 2일에 4.0.1이 릴리즈되었다. 링크 문제는, 꽤 오랫동안 진행한 이전 프로젝트에서 xUnit을 써왔기에 이러한 사실을 전혀 모르고 있었다는 것이다. 최신 버전과 서드파티 IDE의 문제 문제는 이런 변경 사항에 대해 아무것도 모른 채 기존 .NET Framework 프로젝트를 .NET 7으로 마이그레이션하다가 테스트 프로젝트가 작동하지 않는 상황에 직면하게 되었다는 것이다. 분명 코드도 정상이고, IDE도 정상이고, NuGet 패키지도 잘 설치되었으며 dotnet test 로 테스트를 실행하면 잘 되는데 JetBrains Rider의 Unit Tests Explorer에서 테스트를 감지하지 못하는 것이었다. Visual Studio에서는? 이럴 때 뭘 해야 할까 생각해보다가 일단 Visual Studio에서 돌려보기로 했다. 왜냐하면 dotnet test 는 잘 돌아갔으므로 Visual Studio에서도 되지 않겠냐는 생각이 들었기 때문이다. 또, Visual Studio가 켜지고 ReSharper를 로드하는 모습을 보니 Visual Studio의 자체 단위 테스트 기능과 ReSharper를 비교해보면 더 확실히 할 수 있지 않을까 하는 생각이 들었다. 이 때까진 몰랐지. 이게 함정이 될 줄은. 아무튼 Visual Studio가 로드되고 프로젝트를 연 뒤, 우선은 ReSharper의 단위 테스트 기능을 먼저 실행하려 시도해봤다. 예상대로 작동하지 않는다. 증상 역시 똑같았다. 아예 단위 테스트 세션 자체가 생기질 않는다. 왜? 감지된 단위 테스트가 없으니까. 그래서 이제 Visual Studio의 자체 단위 테스트 윈도우를 열어봤더니, 아니나 다를까 정상적으로 로드되고 단위 테스트도 문제 없이 진행되는 것이 아닌가? 성급했던 결론 ...

 오늘 오랜만에 JetBrains Rider에서 Visual Studio 2022로 돌아와 작업하던 도중, git 리포지토리가 없는 솔루션에 리포지토리를 만들려고 관련 메뉴를 열어보니 아래와 같이 버튼이 비활성화 되어있었습니다. 비활성화된 Git 리포지토리 만들기 버튼   그래서 Git 메뉴에서 수동으로 하고자 했으나 Git 메뉴도 없었고, 예전 기억을 되살려 파일(F) - 소스 제어에 추가  기능을 사용하려 했으나 이 역시 없었습니다. 존재하지 않는 Git(G)  메뉴 존재하지 않는 소스 제어에 추가 메뉴   그래서 기억을 더 더듬어 보다가, 이유를 떠올렸습니다. 바로 소스 제어 플러그인 이 선택되지 않았을 때 생기는 문제였다는 것을요. 소스 제어 플러그인 선택 이 방법은 Visual Studio 2019에도 확실히 동일하게 적용할 수 있으며, 정확하진 않으나 2017에서도 동일하게 적용할 수 있을 겁니다.   Visual Studio는 JetBrains Rider 등 다른 IDE와 같이 여러 소스 제어 서비스를 사용할 경우를 가정하고 이를 선택할 수 있게 해놨습니다. MS VCS, Git 등등을 선택할 수 있습니다.   그러나 기본적으로 이는 없음 으로 설정되어 있고, 이렇게 되면 위처럼 메뉴도, 버튼도 나타나지 않고 작동하지 않게 됩니다.   그러니 해결 방법은 당연히 이를 활성화하는 것입니다. 옵션   소스 제어 - 플러그인 선택 현재 소스 제어 플러그인을 Git 으로 설정   Visual Studio의 도구 - 옵션 에 들어가 소스 제어 - 플러그 인 선택  메뉴를 열고 현재 소스 제어 플러그인을 Git 으로 설정 하면 문제없이 Git 관련 기능을 사용할 수 있습니다. 나타난 Git(G)  메뉴 사용 가능해진 Git 리포지토리 만들기 버튼 다시 생긴 소스 제어에 추가  버튼 마치며   당연히 이 방법은 지원되는 다른 소스 제어 ...

제목에는 VS Code와 구분짓기 위해 VS 2022를 사용했으나 Visual Studio 2019, 2017 모두 사용 가능한 방법입니다. 첫 번째 방법: 솔루션 탐색기의 활성 문서 동기화 버튼 수동으로 활성 문서 동기화 버튼을 클릭해 동기화하는 방법입니다. 해당 버튼을 누르면 현재 에디터에 열려있는 문서 [1] 가 솔루션 탐색기에 동기화됩니다. 두 번째 방법: 활성 문서 동기화 단축키 사용 마우스를 사용할 필요 없이 단축키를 사용해 동기화하는 방법입니다. 기본 단축키는 Ctrl+[, Ctrl+S 또는 Ctrl+[, S 입니다. 저는 이 바로가기 키가 불편해 Ctrl+Shift+Alt+[, Ctrl+ShiftAlt+; 로 변경해 사용하고 있습니다. 여기서 지정된 단축키를 누르면 첫 번째 방법 의 동기화 버튼을 클릭한 것과 같은 액션이 실행됩니다. 주의할 점 은, 일부 단축키와 충돌이 날 수 있으니 저처럼 사용되지 않는 단축키 위주로 조합하시기 바랍니다. 예를 들어 단축키 조합에  Ctrl+; (기본값: 솔루션 탐색기 검색)과 같은 키가 조합되어 있을 경우엔 작동하지 않을 수 있습니다. 세 번째 방법: 항상 자동으로 동기화 이 방법은 항상 현재 활성화된 문서가 솔루션 탐색기에 자동으로 동기화되도록 설정합니다. 그렇기 때문에 이 옵션이 켜져있을 경우 첫 번째 방법의 활성 문서 동기화 버튼이 표시되지 않습니다. 이 옵션을 키기 위해서는 옵션 - 프로젝트 및 솔루션 - 일반 메뉴의 솔루션 탐색기에서 활성화된 항목 추적 옵션을 체크하시면 됩니다. 포커스된 문서. 즉, 분할 창일 경우에는 마지막으로 활성화된 문서. ↩︎

.Net Core EF 닷넷 코어도 당연히 닷넷 프레임워크와 같이 엔티티 프레임워크를 지원합니다. code-first 마이그레이션 역시 닷넷 프레임워크 EF와 굉장히 비슷합니다. 그러나, 패키지 설치 미스에 따라 곤란한 상황을 겪게 될 수도 있습니다. OnConfiguring 오버라이드 불가 그 문제는 바로 DbContext.OnConfiguring을 오버라이드해 사용해야 하는데, 정작 오버라이드할 DbContext 클래스의 OnConfiguring 메서드가 보이지 않는 문제입니다. OnModelCreating, OnChangeEventHandler등이 보이나, OnConfiguring은 보이지 않는 모습 왜 그럴까요? 사실, 생각해볼 것도 없이, 단순히 지금 여러분이 상속한 DbContext 클래스에 OnConfiguring 메서드가 없기 때문 입니다. 그렇다면 왜 없을까요? 여기서 바로 이 글 처음에 말했던 패키지 설치 미스가 나오게 됩니다. .Net Core EF Code-First를 사용하기 위해 필요한 패키지 닷넷 코어 엔티티 프레임워크를 사용하려면, 당연히 엔티티 프레임워크를 지원하는 DB의 라이브러리가 필요합니다. MySQL, MSSQL, SQLite, … 등등 많은 DB는 현재 엔티티 프레임워크를 지원하는 패키지를 NuGet에 배포하고 있습니다. 하지만, 거기서 끝이 아닙니다. 예를 들어 SQLite를 사용한다고 가정해볼까요? 여러분은 NuGet으로 System.Data.SQLite.Core, System.Data.SQLite.EF6 패키지를 설치할 겁니다. 만약 여기서 끝났다고 생각하고 DbContext를 만들면 위의 이미지와 같은 상황이 생기게 됩니다. 왜냐, System.Data.Entity.DbContext에는 OnConfiguration 메서드가 없기 때문입니다. 여러분이 제대로 된 DbContext를 상속받아 사용하시려면, Microsoft.EntityFrameworkCore 패키지 역시 설치...

.Net Core 3.0 및 C# 8 닷넷 코어 3.0에는 정말 끝내주는 기능들 이 많이 들어있습니다. 특히, C# 8에 추가된 기능들 은 정말 감동의 눈물을 흘릴 지경이죠. 프리뷰 버전, 그리고 버그? 하지만, 아직 프리뷰 버전이라서, VS2019 16 이상 버전을 사용하며 .Net Core 3.0 프리뷰 버전 SDK 를 설치해야만 사용할 수 있다고 합니다. 문제는 여기서 발생하는데요. 버그인지, 아니면 신경을 안 쓴 것인지, .Net Core 3.0 프리뷰 버전을 설치하면 나타나는 WPF App (.NET Core) 프로젝트 를 만들려고 하면 아래와 같이 옵션을 활성화해달라는 메세지가 나타납니다. 옵션 - 프로젝트 및 솔루션 - .NET Core 섹션에서 프리뷰 버전 사용에 체크해달라는 메세지 헌데, 해당 옵션으로 이동해보면 아무것도 없습니다. 띠용 예전같았으면 VS의 언어를 영어로 바꿔보는 등 되도 않는 삽질부터 해봤겠지만, 많이 당해서 경험치가 쌓인 지금은 검색부터 하게 됐습니다. 바로 답이 나오더군요. SDK 개발진들의 실수? 버그? 엉뚱한 곳에 있는 프리뷰 활성화 체크박스 해당 체크박스는 프로젝트 및 솔루션 하위의 항목이 아닌, 환경(Environment) - 미리 보기 기능(Preview Features) 항목에 있었습니다. 환경 - 미리 보기 기능 항목에 있는 .NET Core 미리 보기 사용 체크박스 이제 저걸 체크하고 다시 프로젝트를 만들면 정상적으로 생성되는 모습을 볼 수 있습니다. 모두 즐코딩하세요. ​

반복되는 마무리 처리 오늘, 단위 테스트를 진행하다가 난감한 상황을 맞닥뜨렸습니다. 단위 테스트 대상 메서드는 ADB를 통해 특정 작업을 시행한 뒤 Redirect된 출력을 바탕으로 내용을 분석해 원하는 결과가 나왔는지 체크하는 메서드였는데요. 문제는, ADB 프로세스를 처음 실행할 때, 데몬 모드로 프로세스가 꺼지지 않게 계속 실행된다는 것 입니다. 이 문제를 해결하기 위해서, 여러 시도를 했습니다. 우선, 매 adb 명령이 완료될 때마다 프로세스 리스트에서 adb를 모두 종료하는 방식이 첫번째였죠. 하지만, 이 경우에 ADB 작업이 실행될 때마다 데몬이 켜지길 반복 하기 때문에, 심각할 정도의 CPU 자원 낭비 , 즉 딜레이 가 생겼습니다. 그래서, ADB 관련 처리를 하는 클래스에 IDisposable 을 구현한 뒤, Dispose() 메서드에서 전체 adb 프로세스를 죽이는 작업을 처리하도록 했습니다. 이러면 아래와 같이 사용할 수 있죠. using ( var manager = new AdbManager()) { // TODO: Process... } 실사용에선 별 문제가 없어 보입니다. 그렇지만, 고작 단위 테스트 하나를 위해서 저렇게 해야될까요? 당연히 아닙니다. 제가 사용하는 NUnit 테스트 프레임워크엔 이럴 경우를 위한 어트리뷰트가 마련돼 있습니다. 물론, 다른 프레임워크도 비슷한 기능이 있으나, 이번에 제가 포스팅할 것은 제가 사용하는 NUnit에 대해서입니다. SetUpAttribute, TearDownAttribute 바로 SetUpAttribute 와 TearDownAttribute 입니다. 각각 단위 테스트를 시작하기 전, 그리고 단위 테스트를 마친 후 시행될 작업을 정의할 메서드에 붙여주시면 됩니다. 지금 제 상황에 맞게 코딩해볼까요? [TestFixture] public class AdbManagerTests { // 다른 수많은 비슷한 테스트 메서드들... [...

디버그의 필수요소. 이 라인까지 실행 후 BREAK   디버그를 하다 보면 break포인트만으로는 감당할 수 없는 상황이 자주 생깁니다. 예를 들어 다음과 같은 코드가 있다고 생각해보세요. if (elemMore != null ) { Log.InfoFormat( "어떠어떠한 로그를 출력!" ); CurrentPage.Click(elemMore); CurrentPage.WaitForNetworkIdle0( 30000 ); if (_isPageTabNewWindowCreated == false ) GoBackCount++; }   이제 디버그를 돌립니다. 첫줄의 if문에 breakpoint를 걸고, 다음과 같은 프로세스를 따르고자 합니다. elemMore이 null인지 체크 null이 아니어야 함. elemMore가 제대로 스크롤된 후 클릭되는지 확인. _isPageTabNewWindowCreated가 true로 변경되었는지 확인.   자, 여기서 가장 효율적인 디버깅 방법은 뭘까요? 언뜻 생각해서는, 추가로 Click 메서드에 breakpoint를 걸고, WaitForNetworkIdle0에도 걸고, 그 밑의 if문에도 걸고… 그리고 실행한 뒤 F5를 눌러가며 breakpoint를 따라 디버깅하는 방법이 최선이라 생각할 수도 있습니다.   그러나 Visual Studio에서는 그러한 노가다를 방지하기 위한 효과적인 방법을 제시해줍니다. 바로 ‘현재 커서까지 실행’ 이라는 기능이죠. 이 기능을 사용하면, 현재 커서(마우스 커서가 아닙니다. Character 커서입니다.)까지 실행한 뒤 알아서 중지됩니다.   그럼, 어떻게 써야할까요? 커서까지 실행   위의 초록색 재생 버튼이 보이시나요? 디버그 중 breakpoint에 걸린 상태에서, 즉 일시 중지된 상태에서 특정 라인에 마우스를 올려두면 저렇게 초록색 여기까지 ...

최신기술을 맹신하다가 프로젝트 한 개가 통채로 날아가게 된 사건 바로 오늘 있던 일입니다. 최근 두 달간 3년 가까이 진행되어온 프로젝트의 마무리 및 약간의 보수 작업을 해왔습니다. 핵심 라이브러리를 다른 라이브러리로 대체하는 작업이었죠. 기존 프로젝트가 여러 사람이 달라붙어서 작업한다는 전제가 없었기 때문에, 주석도 완벽하지 않고 프로젝트 구조 파악도 어려워 기존 라이브러리를 사용하는 클래스들을 수정하는 것이 아닌, 기존 클래스명에 특정 접두사를 붙여 다른 네임스페이스에 새로운 라이브러리를 사용해 같은 프로세스를 진행하는 클래스를 만들게 되었습니다. 이를 위해, 우선 기존 클래스의 본문을 복사해 접두사가 붙은 새로운 클래스의 본문에 붙여넣고 , 기존 라이브러리에서 새로운 라이브러리로 대체되는 부분만 수정 하는 작업을 진행했죠. 물론, 기존 라이브러리에서 지원하지 않거나 새로운 라이브러리에서 지원하지 않는 부분은 추가/제거 작업을 병행했습니다. 숨겨진 양날검: ReSharper Code Cleanup 그런데 이렇게 하고 보니 코드가 영 보기 좋지 않았습니다. 처음부터 클래스를 작성했으면 모를까, 이미 붙여넣어진 수천줄의 코드에서 뺄 부분을 빼고 추가할 부분을 추가하고 수정할 부분을 수정하다 보니 개행도 엉망진창, 들여쓰기도 엉망진창, 급했던 부분에선 띄어쓰기도 엉망진창인 상태 가 되었습니다. 하지만 이러면 어떠하고 저러면 어떠하리, 저에겐 사랑스런 ReSharper가 있었고, 여기엔 VS 기본 코드 클린업과는 비교도 되지 않는 강력한 클린업 기능이 있습니다. 단순 줄 정리, 들여쓰기 정리는 물론, auto property로 만들 수 있는 프로퍼티는 auto property로 자동으로 만들어주고, 람다 메서드로 만들 수 있는 부분은 람다 메서드로 만들어주고, 읽기 전용으로 만들 수 있는 필드는 읽기 전용으로, 오토 프로퍼티 중 get만 사용할 수 있는 프로퍼티는 get만 남기고, String, Boolean등을 자동...