언제 그리고 왜-데이터를 Windows 레지스트리에 저장해야합니까?

개발자에게는 레지스트리에 구성 / 옵션을 저장하는 도구가 제 인생의 골칫거리입니다. 나는 그 옵션에 대한 변경 사항을 쉽게 추적 할 수 없으며, 기계에서 기계로 쉽게 이식 할 수 없으며, .INI 파일의 좋은 날을 정말로 열망하게 만듭니다 ...

내 응용 프로그램을 작성할 때 구식 구성 파일이 아닌 레지스트리에 무엇을 넣어야합니까? 그 이유는 무엇입니까?

• 원래 (WIN3) 구성은 windows 디렉토리의 WIN.INI 파일에 저장되었습니다.
• 문제 : WIN.INI가 너무 커졌습니다.
• 솔루션 (Win31) : 프로그램과 같은 디렉토리에있는 개별 INI 파일.
• 문제 : 해당 프로그램이 네트워크에 설치되어 많은 사람들이 공유 할 수 있습니다.
• 솔루션 (Win311) : 사용자의 Window 디렉토리에있는 개별 INI 파일.
• 문제 : 많은 사람들이 Windows 폴더를 공유 할 수 있으며 어쨌든 읽기 전용이어야합니다.
• 솔루션 (Win95) : 각 사용자마다 별도의 섹션이있는 레지스트리.
• 문제 : 레지스트리가 너무 커졌습니다.
• 솔루션 (WinXP) : 개별 데이터의 큰 블록이 사용자 고유의 Application Data 폴더로 이동되었습니다.
• 문제 : 많은 양의 데이터에는 적합하지만 소량에는 다소 복잡합니다.
• 솔루션 (.NET) : 응용 프로그램과 동일한 폴더에있는 .config (Xml) 파일에 저장된 소량의 고정 된 읽기 전용 데이터와 API를 사용하여 읽습니다. (읽기 / 쓰기 또는 사용자 별 데이터는 레지스트리에 유지됨)

사용자 관점과 프로그래머 관점 모두 에서이 작업을 수행하면 파일 연결이나 컴퓨터 특정 설정과 같은 것이 아니라면 레지스트리에 무언가를 넣는 것이 좋은 변명이 아니라고 말할 수 있습니다.

프로그램이 설치된 곳 어디에서나 프로그램을 실행할 수 있어야하고 설치가 기계 내에서 또는 다른 기계로 완전히 움직여야하며 실행에 영향을 미치지 않아야한다고 생각하는 학교 출신입니다.

구성 가능한 옵션 또는 필수 dll 등이 공유되지 않은 경우 설치 디렉토리의 하위 디렉토리에 있어야 전체 설치를 쉽게 이동할 수 있습니다.

나는 프로그램과 같은 작은 유틸리티를 많이 사용하므로 USB 스틱에 설치하고 다른 컴퓨터에 꽂아서 실행할 수 없다면 그것은 아닙니다.

Microsoft 정책 :

• Windows 95 이전에는 응용 프로그램 데이터로 ini 파일을 사용했습니다.
• Windows 95-XP 시대에는 레지스트리를 사용했습니다.
• Windows Vista에서는 이제 XML을 기반으로하지만 ini 파일을 사용합니다.

레지스트리는 시스템에 따라 다릅니다. 나는 느려지기 때문에 그것을 좋아하지 않았으며 필요한 것을 찾는 것이 거의 불가능합니다. 그래서 간단한 ini 또는 다른 설정 파일을 좋아합니다. 위치 (애플리케이션 폴더 또는 사용자 폴더)를 알기 때문에 쉽게 이식 가능하고 사람이 읽을 수 있습니다.

시기 -레거시 통합으로 인해 또는 고객의 sysadmin이 "그렇게 할 것"이라고 말했거나 XML을 사용하기 어려운 구식 언어로 개발 중이기 때문에 강제로해야합니다.

이유 -주로 레지스트리는 응용 프로그램 옆에있는 구성 파일을 복사하는 것만 큼 이식성이 떨어지기 때문에 거의 동일합니다.

.Net2 +를 사용하는 경우 App.Config 및 User.Config 파일이 있으며 레지스트리에 DLL을 등록 할 필요가 없으므로 멀리하십시오.

구성 파일에는 자체 문제가 있지만 (아래 참조) 코드를 작성하여 아키텍처를 변경할 수 있습니다.

• 문제 : 응용 프로그램에서 구성 가능한 설정이 필요했습니다.
• 해결 방법 : Windows 폴더의 파일 (WIN.INI)에 설정을 저장하십시오. 섹션 제목을 사용하여 데이터를 그룹화하십시오 (Win3.0).
• 문제 : WIN.INI 파일이 너무 커져서 복잡해졌습니다.
• 해결 방법 : INI 파일의 설정을 응용 프로그램 (Win3.1)과 같은 폴더에 저장하십시오.
• 문제 : 사용자 별 설정이 필요합니다.
• 솔루션 : 사용자 설정은 사용자의 INI 파일에있는 사용자의 Window 디렉토리 (Win3.11) 또는 사용자 특정 섹션에있는 사용자 별 INI 파일에 저장하십시오.
• 문제 : 보안-일부 응용 프로그램 설정은 읽기 전용이어야합니다.
• 해결 방법 : 보안과 사용자 별 및 컴퓨터 전체 섹션 (Win95)이있는 레지스트리.
• 문제 : 레지스트리가 너무 커졌습니다.
• 해결 방법 : 사용자 별 레지스트리가 사용자 자신의 "Application Data"폴더에서 user.dat로 이동하고 로그인 (WinNT)시에만로드되었습니다.
• 문제 : 대기업 환경에서는 여러 컴퓨터에 로그온하여 각각을 설정해야합니다.
• 해결 방법 : 로컬 (로컬 설정)과 로밍 (응용 프로그램 데이터) 프로필 (WinXP)을 구별하십시오.
• 문제 : xcopy를 나머지 .Net처럼 응용 프로그램을 배포하거나 이동할 수 없습니다.
• 솔루션 : 응용 프로그램과 동일한 폴더에있는 APP.CONFIG XML 파일-읽기 쉽고 조작하기 쉽고 이동하기 쉬우 며 변경시 추적 할 수 있습니다 (.Net1).
• 문제 : 여전히 사용자 별 데이터를 유사한 (즉, xcopy 배포) 방식으로 저장해야합니다.
• 솔루션 : 사용자의 로컬 또는 로밍 폴더에 USER.CONFIG XML 파일이 있고 강력한 형식 (.Net2)입니다.
• 문제 : CONFIG 파일은 대소 문자를 구분하며 (사람에게는 직관적이지 않음) 매우 특정한 열기 / 닫기 "태그"가 필요합니다. 연결 문자열은 런타임에 설정할 수 없으며 설정 프로젝트는 레지스트리처럼 쉽게 설정을 쓸 수 없으며 쉽게 결정할 수 없습니다 user.config 파일 및 사용자 설정은 각각의 새 개정이 설치 될 때마다 나타납니다.
• 솔루션 : ITEM 멤버를 사용하여 런타임시 연결 문자열을 설정하고 설치 중에 App.Config를 변경하기 위해 Installer 클래스에 코드를 작성하고 사용자 설정을 찾을 수없는 경우 애플리케이션 설정을 기본값으로 사용하십시오.

몇 개의 창 위치와 가장 최근에 사용한 항목 목록을 Windows 레지스트리에 저장하면 세상이 끝날까요? 지금까지는 잘 작동했습니다.

HKEY-CURRENT-USER는 사소한 사용자 데이터를 소량으로 저장하기에 좋은 장소입니다. 그게 다야. 다른 사람들이 그것을 남용했기 때문에 의도 된 목적으로 사용하지 않는 것은 어리석은 것처럼 보입니다.

사용자의 로밍 프로필에서 사용할 수있는 설정은 실제로 사용자의 Application Data 폴더를 직접 찾아 보지 않으려는 경우가 아니라면 레지스트리에 있어야합니다. :-)

레지스트리 읽기 및 쓰기는 스레드로부터 안전하지만 파일은 그렇지 않습니다. 따라서 프로그램이 단일 스레드인지 여부에 따라 다릅니다.

당신이 새로운 응용 프로그램을 개발하고 휴대 성 신경 경우에 당신은해야 결코 (-이 명백한 경우가 있습니다 만, 종종 간과됩니다 대만족 주) 다른 OS가 (창) 레지스트리를 가지고 있지 않기 때문에 윈도우의 데이터가 레지스트리에 저장하지 않습니다.

Win 플랫폼 전용으로 개발하는 경우 ... 가능한 한 피하십시오. 구성 파일 (아마도 암호화 된)이 더 나은 솔루션입니다. 레지스트리에 데이터를 저장하는 데는 아무런 이점이 없습니다. 예를 들어 .NET을 사용하는 경우 격리 된 저장소가 훨씬 더 나은 솔루션입니다.

주제를 약간 벗어 났지만 이식성에 관심이있는 사람들을 보았으므로 내가 사용한 가장 좋은 방법은 Qt의 QSettings 클래스입니다. 설정 저장소를 추상화합니다 (Windows의 레지스트리, Mac OS의 XML 기본 설정 파일 및 Unix의 Ini 파일). 수업의 클라이언트 인 저는 레지스트리 나 다른 것에 대해 궁금해하는 두뇌주기를 소비 할 필요가 없습니다. Just Works (tm).

http://doc.trolltech.com/4.4/qsettings.html#details

일반적으로 레지스트리에 설정을 저장하지 않으면 주로 현재 Windows 설정을 가져오고 파일 연결을 변경하는 데 사용됩니다.
이제 소프트웨어가 이미 설치되어 있는지 감지해야하는 경우 레지스트리에 최소한의 항목을 만들 수 있습니다. , 이는 모든 구성에서 다시 찾을 수있는 위치입니다. 또는 응용 프로그램 데이터에서 지정된 이름의 폴더를 검색하십시오.

문서 및 설정 폴더를 보면 폴더 설정을 위해 Unix 도트 표기법을 사용하는 많은 소프트웨어가 있습니다. .jindent .jogl_ext 등

응용 프로그램 데이터에는 편집기 이름 또는 소프트웨어 이름이있는 다양한 폴더가 있습니다. 적어도 휴대용 응용 프로그램 중 현재 추세 인 것처럼 보입니다 ...
WinMerge는 레지스트리에 데이터를 저장하지만 구성 대화 상자에서 옵션의 가져 오기 및 내보내기를 제공하는 약간 다른 접근 방식을 사용합니다.

개인적으로 레지스트리를 사용하여 (제거) 설치 스크립트에서 사용할 설치 경로를 저장했습니다. 이것이 유일한 옵션인지 확실하지 않지만 합리적인 솔루션처럼 보였습니다. 이것은 물론 Windows에서만 사용되는 앱을위한 것입니다.

.NET에는 실제로 필요한 것이 없습니다.

다음은 Project 속성을 사용하여이를 수행하는 방법을 보여주는 두 가지 예입니다.

이 예제는 Windows User Project Properties에서 수행하지만 Application에서도 동일하게 수행 할 수 있습니다.

여기 더 :

http://code.msdn.microsoft.com/TheNotifyIconExample

http://code.msdn.microsoft.com/SEHE

(토론과 관련이 있지만) 짧은 답변 : 그룹 정책.

고객의 IT 부서에서 링크 속도, 사용자 지정 오류 메시지 또는 연결할 데이터베이스 서버와 같이 Windows 또는 작성하거나 번들로 제공하는 구성 요소와 관련된 설정을 적용하려는 경우 여전히 그렇습니다. 레지스트리에 저장된 설정으로 궁극적으로 표시되는 그룹 정책을 통해 수행됩니다. 이러한 정책은 Windows가 시작되거나 사용자가 로그인 한 시점부터 시행됩니다.

구성 요소의 설정을 레지스트리 위치에 매핑 할 수있는 사용자 지정 ADMX 템플릿을 만드는 도구가 있으며 관리자에게 적용해야하는 정책을 적용하면서 이러한 방식으로 적용하기에 의미있는 설정 만 표시하는 공통 인터페이스를 관리자에게 제공합니다.

Windows Registry는 좋은 아이디어라고 생각하지만 응용 프로그램 개발자의 큰 악용과 Microsoft가 권장하지 않는 표준 정책으로 인해 관리 할 수없는 짐승이되었습니다. 나는 당신이 언급 한 이유로 그것을 사용하는 것을 싫어하지만, 그것을 사용하는 것이 합리적 인 경우가 있습니다.

• 응용 프로그램을 제거한 후 응용 프로그램 추적을 남겨 둡니다 (예 : 응용 프로그램을 다시 설치 한 경우 사용자의 기본 설정 기억)
• 다른 응용 프로그램-구성 요소간에 구성 설정 공유