로컬에선 잘 되는데... 원격지에서 클론한 레포지토리에서 특정 파일에 대해 module not found가 뜬다면?

로컬에선 잘 되는데... 원격지에서 클론한 레포지토리에서 특정 파일에 대해 module not found가 뜬다면? Case-Sensitive 주의 그렇다면 무조건 대소문자 문제가 아닌지 확인하도록 하자. 하필이면 딱 한 글자, i와 I의 차이로 인해 3시간이 넘도록 개 뻘짓을 해버렸다. 부디 이 글을 읽고 향후에 이런 개떡같은 운명에 마주치지 않길 바란다. git config core.ignorecase 일단, 첫 번째로 할 건 case-insensitive OS, 특히 윈도우를 사용 중일 때 레포지토리 루트에서 다음 명령어를 실행하는 것이다. git config core . ignorecase false 그렇지 않으면 나처럼 일을 두 번 하게 될 것이다. 위 git config를 적용하면, git이 이후 해당 레포지토리 내의 파일의 대소문자 변경을 감지하게 된다. 즉, headerIcon.png 파일이 headericon.png 로 변경됐을 때 headerIcon.png 파일은 없어진 것으로 판단하고, headericon.png 파일은 새로 생긴 것으로 판단하게 된다. 이 설정을 선행하지 않고 아래 지침을 따르게 되면 파워쉘 스크립트나 배치 파일로(혹은 일일히 UI로) 파일명을 바꿨다가 다시 원본 파일명으로 돌려야 하게 될 것이다. Case-Sensitive한 파일명 변경 이제 코드에서 사용하는 경로와 일치하도록 파일명을 변경한다. 예를 들어, 코드에서 import HeaderIconImage from "@images/icons/headericon.png" 를 사용한다면 headerIcon.png 를 headericon.png 로 변경하면 된다. 나 같은 경우에는 다른 개발자의 프로젝트 파일을 그대로 복사해왔는데… 설마 같은 폴더 내의 수십개의 headericon-*.png 파일이 각각 i 와 I 가 번갈아가며 썼을 줄은 몰랐다. 후… 가능하면 이름 컨벤션은 일치시키도록 하자

MSTSC를 통한 저장된 자격 증명으로 원격 연결 시 Defender Credential Guard가 허용하지 않는 문제

이미지
MSTSC를 통한 저장된 자격 증명으로 원격 연결 시 Defender Credential Guard가 허용하지 않는 문제 원격 연결, MSTSC 업무를 하다 보면 자주 다른 컴퓨터에 원격으로 연결해야 할 일이 생깁니다. 리눅스 계열은 SSH로, 윈도우 계열은 SSH를 쓸 때도 있지만 대부분 RDP를 통해 GUI로 원격 연결해 사용하게 됩니다. 그러나 최근 일 년간은 윈도우 서버에 연결할 일이 거의 없다시피 하여 MSTSC.EXE라는 실행 파일 이름조차 잊고 지내다가 다시 윈도우 서버로 연결할 일이 생겨서 연결하려 했는데 다음과 같은 문제가 생겼습니다. Windows Defender Credential Guard, 넌 못 지나간다 자격 증명이 허용되지 않아 두 번째 연결부터 위처럼 Windows Defender Credential Guard가 길을 가로막아버리는 것이 바로 그 문제였습니다. 뭐 그룹 정책 관리자에서 어쩌구… RDP 파일을 저장해서 저쩌구… 이런 건 전부 작동하지 않았습니다. 심지어 비밀번호도 드럽게 길어서 매번 연결할 때마다 패스워드를 복붙하는 과정도 엄청나게 귀찮았습니다. 해결 방법 해결 방법은 생각보다 간단했습니다. 구글에 검색하니 바로 이런 스택 익스체인지 글 이 나와서 따라하니 바로 되더라고요. 해결 방법만 적자면 다음과 같습니다. cmdkey /list:TERMSRV/* 명령을 통해 대상 원격 연결을 확인. (한 번도 연결한 적 없는 서버라면 생략 가능) cmdkey /delete:[확인된 대상] 명령을 통해 기존 대상 삭제. (한 번도 연결한 적 없는 서버라면 생략 가능) 예: cmdkey /delete:TERMSRV/1.2.3.4 cmdkey /generic:TERMSRV/[IP] /user:[로그온 유저] /pass:[로그온 패스워드] 명령을 통해 새로운 자격 증명 등록 예: cmdkey /generic:TERMSRV/1.2.3

ASP.NET에서 인증 필터를 만들어 쓰는데 DbContext 에러가 났다.

ASP.NET에서 인증 필터를 만들어 쓰는데 DbContext 에러가 났다. 어처구니 없는 실패 ASP.NET에서 권한 레벨 기능을 도입하는 중에 IAuthorizationFilter를 구현한 커스텀 필터를 제작해 사용하려 했는데, 다음과 같은 에러가 지속적으로 발생했다. System . InvalidOperationException : A second operation was started on this context instance before a previous operation completed . This is usually caused by different threads concurrently using the same instance of DbContext . For more information on how to avoid threading issues with DbContext , see https : / / go . microsoft . com / fwlink / ? linkid = 2097913 . at Microsoft . EntityFrameworkCore . Infrastructure . Internal . ConcurrencyDetector . EnterCriticalSection ( ) at Microsoft . EntityFrameworkCore . Query . Internal . SingleQueryingEnumerable` 1 . AsyncEnumerator . MoveNextAsync ( ) at Microsoft . EntityFrameworkCore . EntityFrameworkQueryableExtensions . ToListAsync [ TSource ] ( IQueryable` 1 source , CancellationToken cancellationToken ) at Microsoft . EntityFrameworkCore . EntityFram

WPF에서 폰트 설치 없이 외부 폰트를 사용하는 방법

WPF에서 폰트 설치 없이 외부 폰트를 사용하는 방법 외부 폰트 사용: WPF 앱에서 폰트 설치 없이 사용하기 WPF(Windows Presentation Foundation) 앱 개발 중 외부 폰트를 사용해야 하는 상황이 발생할 수 있습니다. 흔한 경우는 아니지만, 특정 디자인 요구사항이나 클라이언트 요청에 따라 외부 폰트를 적용해야 할 때가 있습니다. 외부 폰트는 시스템에 기본적으로 설치되어 있지 않은 폰트를 의미하며, 앱 실행 시 폰트 설치 없이 사용할 수 있도록 하는 것이 중요합니다. 외부 폰트가 필요한 경우 대부분의 WPF 앱은 설치 파일 형태로 배포되기 때문에, 설치 과정에서 폰트를 함께 설치할 수 있습니다. 하지만, 포터블 방식으로 배포되는 앱의 경우, 관리자 권한이 없을 경우 폰트 설치가 불가능하므로 외부 폰트를 사용해야 합니다. 외부 폰트 사용 방법: 폰트 리소스 활용 외부 폰트를 사용하는 가장 효율적인 방법은 폰트 파일을 어셈블리 리소스에 포함시키는 것입니다. 이렇게 하면 폰트 설치 없이 앱 실행 시 폰트를 로드하여 사용할 수 있습니다. 1. 폰트 파일을 프로젝트에 포함: 원하는 폰트 파일(.ttf)을 WPF 프로젝트에 추가하고, 빌드 작업을 "리소스"로 설정합니다. XML <ItemGroup> <Resource Include="Fonts\내폰트.ttf" /> </ItemGroup> 2. FontFamily 속성에 폰트 로드: 컨트롤(예: TextBlock)의 FontFamily 속성에 리소스에 포함된 폰트를 로드하여 사용합니다. 이때, 주의할 점은 폰트 파일명이 아닌 실제 폰트 이름 을 사용해야 한다는 것입니다. XML <TextBlock FontFamily="Fonts/#Pretendard Variable" /> 주의 사항: 폰트 이름 확인: 폰트 파일을 탐색기

Next.js와 MUI의 병용이 더 쉬워졌다!

Next.js와 MUI의 병용이 더 쉬워졌다! Next.js 및 MUI를 함께 사용하자 (feat. Tailwind CSS) 바로 저번 주까지만 해도 Next.js와 MUI를 함께 사용하려면 캐시 처리 및 인젝션 오더 설정용 프로바이더를 직접 공식 문서에 따라 만들고 커스텀해 삽입하는 노가다가 필요했다. 하지만 이제 그럴 필요가 없어진 것 같다. 포트폴리오용 사이트를 제작하기 위해 MUI 문서 를 들어가보니 새로운 방법이 제시되어 있었기 때문이다. 변경된 사용 방법 우선 각 단계를 진행하기 전에 기본적인 MUI 구성 은 완료되어 있어야 한다. 또한 문서에서는 Next.js 13 이상에서 진행하기를 권장하고 있다. 나는 pnpm 패키지 매니저를 사용하므로 다른 패키지 매니저를 사용한다면 적절히 변환해서 사용하면 된다. App Router에서 사용하기 1. 필요한 패키지 설치 : pnpm add @mui/material-nextjs @emotion/cache 명령어로 필요한 의존성을 추가한다. 2. 설정 : app/layout.tsx 에서 AppRouterCacheProvider 를 사용해 <body> 안의 요소를 감싼다. // app/layout.tsx + import { AppRouterCacheProvider } from '@mui/material-nextjs/v13-appRouter'; // or `v14-appRouter` if you are using Next.js v14 export default function RootLayout(props) { const { children } = props; return ( <html lang="en"> <body> + <AppRouterCacheProvider>{children}</AppRouterCacheProvider>

Next.js와 MUI의 병용이 더 쉬워졌다!

Next.js와 MUI의 병용이 더 쉬워졌다! Next.js 및 MUI를 함께 사용하자 (feat. Tailwind CSS) 바로 저번 주까지만 해도 Next.js와 MUI를 함께 사용하려면 캐시 처리 및 인젝션 오더 설정용 프로바이더를 직접 공식 문서에 따라 만들고 커스텀해 삽입하는 노가다가 필요했다. 하지만 이제 그럴 필요가 없어진 것 같다. 포트폴리오용 사이트를 제작하기 위해 MUI 문서 를 들어가보니 새로운 방법이 제시되어 있었기 때문이다. 변경된 사용 방법 우선 각 단계를 진행하기 전에 기본적인 MUI 구성 은 완료되어 있어야 한다. 또한 문서에서는 Next.js 13 이상에서 진행하기를 권장하고 있다. 나는 pnpm 패키지 매니저를 사용하므로 다른 패키지 매니저를 사용한다면 적절히 변환해서 사용하면 된다. App Router에서 사용하기 1. 필요한 패키지 설치 : pnpm add @mui/material-nextjs @emotion/cache 명령어로 필요한 의존성을 추가한다. 2. 설정 : app/layout.tsx 에서 AppRouterCacheProvider 를 사용해 <body> 안의 요소를 감싼다. // app/layout.tsx + import { AppRouterCacheProvider } from '@mui/material-nextjs/v13-appRouter'; // or `v14-appRouter` if you are using Next.js v14 export default function RootLayout(props) { const { children } = props; return ( <html lang="en"> <body> + <AppRouterCacheProvider>{children}</AppRouterCacheProvider>

GitLab Runner for Windows에서 filename too long 문제 발생

GitLab Runner for Windows에서 filename too long 문제 발생 Filename To Long… Electron 관련 프로젝트가 자동으로 배포되도록 파이프라인을 구성했다. 리눅스 쪽 러너에서는 문제가 없는데 Windows 러너쪽에서 계속 실패를 하여 로그를 확인해보니 filename too long 에러가 발생하고 있었다. 원인이 되는 경로는 node_modules/* 쪽이었는데 이걸 뭐 어떻게 건드릴 수 있는 상황이 아닌 건 둘째 치더라도, 현재 레지스트리에서 긴 파일 경로를 허용 해놓은 상태인데 이게 왜 뜨는지 알 수가 없었다. git config 원인은 엉뚱하게도 git 설정에 있었다. 발견했을 때는 황당했는데, 아무래도 내부적으로 git 관련 커맨드를 사용하는 게 아닌가 싶다. core.longpaths 이 증상을 해결하는 데 내가 사용한 방법은 core.longpaths 를 true 로 설정하는 것이다. git config --system core.longpaths true 위 명령어를 관리자 권한의 파워쉘에서 실행한 뒤 실패한 Job을 재가동하니 정상적으로 작동했다.