Windows 레지스트리에 데이터를 저장해야 하는 시기와 이유는 무엇입니까?

Windows 레지스트리에 데이터를 저장해야 하는 시기와 이유는 무엇입니까?

개발자로서 레지스트리에 구성/옵션을 저장하는 도구는 제 인생의 골칫거리입니다.저는 이러한 옵션의 변경 사항을 쉽게 추적할 수 없고, 시스템 간에 쉽게 이식할 수 없으며, 이 모든 것이 저를 정말로 그리워하게 만듭니다.INI 파일...

애플리케이션을 직접 작성할 때 구식 구성 파일이 아닌 레지스트리에 넣어야 하는 것은 무엇이며, 그 이유는 무엇입니까?

• 원래 (WIN3) 구성은 WIN에 저장되었습니다.윈도우즈 디렉터리의 INI 파일입니다.
• 문제: WIN.INI가 너무 컸습니다.
• 솔루션(Win31): 프로그램과 동일한 디렉토리에 있는 개별 INI 파일.
• 문제:그 프로그램은 네트워크에 설치되어 많은 사람들이 공유할 수 있습니다.
• 솔루션(Win311): 사용자의 Window 디렉토리에 있는 개별 INI 파일입니다.
• 문제:많은 사용자가 Windows 폴더를 공유할 수 있으므로 읽기 전용이어야 합니다.
• 솔루션(Win95):각 사용자에 대해 별도의 섹션이 있는 레지스트리.
• 문제:레지스트리가 너무 큽니다.
• 솔루션(WinXP): 개별 데이터의 큰 블록이 사용자 자신의 애플리케이션 데이터 폴더로 이동됩니다.
• 문제:대량의 데이터에는 적합하지만 소량의 데이터에는 복잡합니다.
• 솔루션(.)NET): 응용 프로그램과 동일한 폴더의 .config(Xml) 파일에 저장된 소량의 고정 읽기 전용 데이터 및 이를 읽기 위한 API. (읽기/쓰기 또는 사용자별 데이터는 레지스트리에 유지됨)

사용자의 관점과 프로그래머의 관점 모두에서 볼 때, 저는 파일 연결이나 기계별 설정과 같은 것이 아니라면 레지스트리에 무언가를 넣는 것은 정말 좋은 예외가 아니라고 말해야 할 것입니다.

저는 프로그램이 설치된 곳이라면 어디서든지 실행할 수 있어야 하고, 설치가 기계 내에서 완전히 이동할 수 있어야 하며, 심지어 다른 기계로 이동할 수 있어야 하며, 실행에 영향을 미치지 않아야 한다고 생각하는 학파에서 왔습니다.

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

저는 프로그램과 같은 작은 유틸리티를 많이 사용하기 때문에 USB 스틱에 설치하고 다른 기계에 꽂고 그냥 실행할 수 없다면 저에게는 적합하지 않습니다.

시기 - 레거시 통합이나 고객의 sysadmin이 "그럴 것이다"라고 말하거나 XML을 사용하기 어렵게 만드는 오래된 언어로 개발 중이기 때문에 어쩔 수 없습니다.

이유 - 기본적으로 레지스트리가 응용 프로그램 옆에 있는 구성 파일을 복사하는 것만큼 이동성이 높지 않기 때문입니다(거의 동일하다고 함).

를 사용하는 경우.넷2+ 앱이 있습니다.구성 및 사용자.구성 파일을 사용하면 레지스트리에 DLL을 등록할 필요가 없으므로 해당 파일에서 멀리 떨어져 있습니다.

구성 파일에는 고유한 문제가 있지만(아래 참조) 이러한 문제는 코드화되어 아키텍처를 변경할 수 있습니다.

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

Microsoft 정책:

• 윈도우 95 이전에는 애플리케이션 데이터를 위해 ini 파일을 사용했습니다.
• Windows 95 - XP 시대에는 레지스트리를 사용했습니다.
• Windows Vista에서는 현재 xml 기반이지만 ini 파일을 사용합니다.

레지스트리가 컴퓨터에 종속되어 있습니다.속도가 느려지고 필요한 것을 찾는 것이 거의 불가능하기 때문에 저는 그것을 좋아한 적이 없습니다.그래서 간단한 ini나 다른 설정 파일을 좋아합니다.응용프로그램 폴더 또는 사용자 폴더의 위치를 알고 있으므로 쉽게 휴대할 수 있고 사람이 읽을 수 있습니다.

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

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

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

사용자의 로밍 프로필에서 사용할 수 있도록 설정하려면 실제로 사용자의 응용 프로그램 데이터 폴더를 직접 찾으려는 경우를 제외하고 레지스트리에 저장해야 합니다. :-)

새 앱을 개발 중이고 휴대성에 관심이 있다면 다른 OS에는 (윈도우) 레지스트리가 없기 때문에 절대로 윈도우 레지스트리에 데이터를 저장해서는 안 됩니다(두번째 참고 - 이것은 분명하지만 종종 간과될 수 있습니다).

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

약간 주제에서 벗어났지만 휴대성에 대해 걱정하는 사람들을 보기 때문에 제가 사용한 가장 좋은 접근법은 Qt의 QSettings 클래스입니다.설정의 저장소(Windows의 레지스트리, Mac OS의 XML 기본 설정 파일 및 Unix의 Ini 파일)를 추상화합니다.수업의 고객으로서, 저는 레지스트리나 다른 것에 대해 궁금해하며 두뇌 사이클을 보낼 필요가 없습니다. 바로 작동합니다(tm).

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

개인적으로 (제거) 스크립트에서 사용할 설치 경로를 저장하기 위해 레지스트리를 사용했습니다.이것이 유일한 가능한 선택인지는 모르겠지만, 현명한 해결책인 것 같았습니다.물론 이것은 Windows에서만 사용되는 앱을 위한 것이었습니다.

일반적으로 레지스트리에 설정을 넣지 않으면 현재 Windows 설정을 가져오거나 파일 연결을 변경하는 등의 용도로 주로 사용합니다.
소프트웨어가 이미 설치되어 있는지 탐지해야 하는 경우 레지스트리에 최소한의 항목을 입력할 수 있습니다. 이는 모든 구성에서 찾을 수 있는 위치입니다.또는 응용프로그램 데이터에서 지정된 이름의 폴더를 검색합니다.

문서 및 설정 폴더를 보면 폴더를 설정하기 위해 유닉스 도트 표기법을 사용하는 소프트웨어가 많이 보입니다. .p4qt .sqlworkbench .squirrel-sqlSunDownloadManager .xngr.antexplor.assistant.CodeBlocks .dbvis .gimp-2.4.jdictionary .jindent .jogl_ext(등)

편집자 이름 또는 소프트웨어 이름을 가진 다양한 폴더가 응용 프로그램 데이터에 포함됩니다.적어도 휴대용 애플리케이션들 사이에서는 요즘 추세인 것 같습니다.
WinMerge는 데이터를 레지스트리에 저장하지만 구성 대화 상자에서 가져오기 및 내보내기 옵션을 제공하는 약간 다른 접근 방식을 사용합니다.

Windows 레지스트리는 좋은 아이디어였지만, 애플리케이션 개발자들의 엄청난 남용과 Microsoft가 장려/의무화하지 않은 표준 정책 때문에 관리하기 어려운 야수로 성장했습니다.말씀하신 이유로 사용하는 것은 싫지만 다음과 같이 사용하는 것이 합리적인 경우가 있습니다.

• 응용프로그램이 제거된 후 응용프로그램의 흔적 남기기(예: 응용프로그램이 다시 설치되는 경우 사용자의 기본 설정 기억)
• 다른 응용프로그램 - 구성요소 간에 구성 설정 공유

.NET에는 실제로 필요가 없습니다.

다음은 프로젝트 속성을 사용하여 이 작업을 수행하는 방법을 보여주는 두 가지 예입니다.

이러한 예제는 Windows 사용자 프로젝트 속성별로 수행되지만 응용 프로그램에서도 동일하게 수행할 수 있습니다.

자세한 내용은 다음과 같습니다.

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

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

(토론에 늦었지만) 단답: 그룹 정책.

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

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

언급URL : https://stackoverflow.com/questions/268424/when-and-why-should-you-store-data-in-the-windows-registry