Honsal's Dailylife

    Copilot이 처음 나오고 얼마 지나지 않았을 때 다른 IDE에서 사용이 가능한지 찾아봤지만 VSCode에서만 사용 가능하다는 정보를 접하고 이후 다시 찾아보지 않고 있었습니다.   그러다가 오늘 새벽에 Copilot이 절실해지는 순간이 찾아왔고, 전 예전에 접했던 정보를 바탕으로 당연히 Rider에 Copilot이 없을거라 생각해 VSCode를 키고 작업을 하고 있었습니다...만,   불편하면 방법을 찾는 게 제 성격인지라 JetBrains의 강력한 FileLayout기능을, 심지어 사용자 정의한 기능을 사용할 수 없는 것에 열이 받아서 JetBrains Rider Copilot으로 검색해봤는데...! JetBrains 플러그인에 대놓고 있었다.   JetBrains 플러그인 페이지 에 대놓고, 당당히, 평점 4.5에 가까이, 작년 10월 29일부터 등록되어 있더군요.   기본적으로 VSCode의 Copilot과 크게 다르지 않고, IDE가 다르므로 UI의 차이점은 다소 존재합니다만, 거기서 거기입니다. 잘 활용하면 코딩 속도가 어마무시하게 빨라진다는 점은 당연히 같으므로 기존에 VSCode에서 사용하시던 분이라면 꼭 설치해 사용하시기 바랍니다.

 High DPC Latency Problem   윈도우 10/11에서 높은 DPC Latency로 인한 불편함을 겪는 빈도가 작년부터 갑자기 급증했습니다. LatencyMon등으로 확인해보면 주로 NVidia 드라이버, 혹은 NTFS 드라이버 쪽에서, 혹은 둘 다에서 높은 DPC 레이턴시가 확인됩니다.   이로 인한 증상으로는, 당연히 전체적인 Windows의 성능 저하가 있으며 체감되는(짜증나는) 증상으로는 Windows Explorer 혹은 일부 Windows Forms 앱, 대부분의 WPF 앱을 드래그/리사이즈 할 때 마우스에 렉이 걸리며 끌리는 현상이 발생하고, 그보다 더 심하게 드래그/리사이즈 하는 윈도우가 미친듯이 늦게 반응하는 현상이 있습니다. 원인 파악   저는 작년 6월 혹은 7월부터 이러한 증상을 인지하기 시작했습니다. 사실 생각해보면 재작년 말 쯤부터 이런 증상이 있었던 것 같긴 한데 그건 정확하지 않고, 확실히 아 뭔가 있구나  하고 인지한 것은 위 시각부터입니다.   인지하게 된 계기는 Windows 11 프리뷰 버전을 설치하면서 발생한 마우스 렉 및 Windows Explorer, 일부 Windows Forms app, 대부분의 WPF app의 리사이즈/드래그시 발생하는 끌림 현상을 목격하면서 이러한 문제가 있다는 것을 인지하게 됐습니다. 이런 증상이 무엇 때문인지 알 수 있게 도와주는 프로그램을 찾다가 LatencyMon 을 알게 되었고, 해당 프로그램을 돌려보니 엔비디아 관련 드라이버 또는 NTFS 관련 드라이버, NTOS 관련 드라이버에서 평균 3ms, 최대 200ms의 DPC Latency가 발생했습니다.   처음에는 Windows 11 문제인 줄 알고 Windows 10으로 롤백했었고, 실제로 롤백한 뒤 얼마동안은 괜찮았기에 Windows 10을 쭉 사용하려 했으나 얼마 지나지 않아 Windows 10에서도 비슷한  증상이 발생하기 시작했습니다. 여기서 비...

방금 뱅킹 사이트에서 다운로드한 PDF 파일을 엑셀에 삽입하려 하니 암호가 걸려있어서 안 된다고 하더군요. 그래서 암호를 해제하고자 Acrobat DC를 오랜만에 설치하려 하는데, 계속 설치 실패가 뜨더라고요. Third party payload installer Adobe Acrobat\Setup.exe failed with exit code: 1603   그냥 일시적 오류인가 싶어 한 번 재시도를 해봐도 똑같은 오류가 나오길래 해당 키워드로 검색을 해보니, Print Spooler 서비스가 꺼져 있으면 발생하는 문제 라고 합니다.   그래서 services.msc 에서 Print Spooler를 사용 설정하고 키니 정상적으로 설치되네요. 심지어 설치 속도도 매우 빠릅니다. 아마 서비스 상태를 확인하는 타임아웃이 길어서 실패하기까지 오래 걸렸나 봅니다.

개발 중에는 때때로 하나의 enum 타입을 가지고 여러 value에 대해 분기해 처리해야 하는 경우가 생깁니다. public enum EnumExample { A, B, C } 위와 같은 enum 타입이 있을 때, 상황이 항상 A이거나, B이거나, C이거나 셋 중 하나로 끝나면 매우 바람직하겠지만 대개 그렇지 않죠. A이거나, A와 B이거나, A와 C거나, B거나, ... 이런 상황이 자주 나옵니다. 그럼 어떻게 코딩해야 할까요? 아래처럼? if (value == EnumExample.A) { // ... } else if (value == EnumExample.A && value2 == EnumExample.B) { // ... } 말이 안 되죠. System.FlagsAttribute Class MSDN 문서 에 따르면, 이 어트리뷰트가 적용된 enum은 비트 필드로 취급될 수 있다고 합니다. 즉, C언어 등에서 사용되는 비트 필드마냥 사용할 수 있게 된다는 뜻이죠. 다음 예시를 보세요. [Flags] public enum FlagsExample { NONE = 0, A = 1, B = 2, C = 4, D = 8, E = 16, } 위와 같이 선언된 enum은 각각의 값이 비트 필드로 취급됩니다. 즉 0은 0000 0000 0000 0000, A는 0000 0000 0000 0001, B는 0000 0000 0000 0010, C는 0000 0000 0000 0100, D는 0000 0000 0000 1000, E는 0000 0000 0001 0000과 같은 식으로 생각하시면 됩니다. 이렇게 되면 어떤 방식의 코딩이 가능해지냐? enum 값에 대한 비트 연산이 가능해집니다. var abc = FlagsExample.A | FlagsExample.B | FlagsExample.C; // abc = A, B, C 따라서 위와 같이 하나의 enum 변수에 여러...

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

 EAP를 사용하기 시작한지 거의 반 년이 되어가는 지금, 드디어 ReSharper 2021.3 버전이 출시되며 Visual Studio 2022를 정식으로 지원하기 시작했습니다. 64비트 프로세스 EAP가 시작될 때 예고했듯, 이 버전부터 ReSharper가 64비트 프로세스로 동작합니다.  해당 블로그 에 따르면 기존 기능들은 여전히 사용 가능함에도 불구하고 메모리 제한이 없어졌기에 기능들이 더 빠르게 동작한다고 합니다.

오늘 일어나보니 제 노트10의 유심 트레이가 죽어있었습니다. 현금도 얼마 없는데 수리비 깨질 것을 생각하니 그냥 핸드폰을 바꾸고 몇 달에 걸쳐 할부금을 납부하는게 이득 아닐까라는 생각이 계속 들더군요. 그래서 핸드폰을 바꾸고자 마음먹고 기종을 찾아보니, 제가 바꾸고자 하는 기종은 Micro SD를 지원하지 않는다는 것을 알게 되었습니다. 따라서 저는 외장 SD카드와 내장 SD카드의 중요 내용을 [1] 컴퓨터에 백업하고자 했는데... 느려터진 탐색기 언제나 그렇듯 이 탐색기가 또 발목을 잡았습니다. 탐색기에서 파일 복사/이동/삭제를 대량으로 할 때에 우선 탐색기는 해당 컨텐츠들 [2] 을 쭉 읽어들입니다. 이건 제 뇌피셜이지만 아마 대량의 파일 복사/이동/삭제시 나타나는 프로그래스바를 표시하기 위해 일단 전체 파일이 몇 개인지 읽어들이는 것 같습니다. 그래야 현재까지 복사/이동/삭제된 파일 수와 전체 파일 수의 비율로 프로그래스바를 표시할 수 있을 테니까요. 아무튼, 이미 저는 대량의 파일 삭제 시 이렇게 느려터진 게 짜증나서 [3] 파워쉘을 통해 빠르게 삭제하는 스크립트를 레지스트리로 컨텍스트 메뉴에 등록해둔 상태였습니다. mtp는 다르다 하지만 핸드폰은 같은 방법을 사용할 수 없었습니다. 정확히 말하면, 기본적으로 파워쉘에서 제공해주는 명령어 셋으로는 불가능했습니다. 단순히 제가 찾지 못한 것일 수도 있지만, 아무튼 찾을 수조차 없었습니다. 하지만 구글, 그리고 스택오버플로우는 언제나 답을 알려주죠. 검색해보니 이런 스택오버플로우 글 을 찾을 수 있었습니다. Shell.Application COM Object MSDN 문서 를 보면 해당 COM Object는 쉘 어플리케이션을 반환합니다. 즉 탐색기 API라고 보셔도 무방할 듯 합니다. 이를 사용하면, 탐색기로 할 수 있는 일을 프로그램화시켜 할 수 있다는 것이죠. 그리고 해당 스택오버플로우 글에서 제시한 방법을 따르면, 다음과 같이 사용이 가능합니다. $shell ...