우리는 우리 dll 중 하나를 참조하는 많은 실행 파일을 가지고 있습니다. DLL 중 하나에서 버그를 발견 했으므로 수정하기 위해 모든 실행 파일을 다시 컴파일하고 재배포하지 않아도됩니다. 제 생각에 dll은 헤더 파일에서 아무 것도 변경하지 않는 한 실행 파일과의 호환성을 유지합니다. 그래서 새로운 클래스 멤버도없고 새로운 함수도 없지만 함수 내의 로직을 변경하면 괜찮을 것입니다. 이 올바른지? 컴파일러마다 다르면 알려주십시오. 문제가 될 수 있습니다.미리 컴파일 된 실행 파일과의 호환성을 유지하면서 dll을 변경할 수 있습니까?
귀하의 이해가 정확합니다. 논리는 변경하지만 인터페이스는 변경하지 않는 한 호환성 문제가 발생하지 않습니다.
DLL 인터페이스가 함수 시그니처 이상인 경우주의해야합니다. 예를 들어 원래 DLL이 int 매개 변수를 허용했지만 새 DLL이이 매개 변수의 값이 양수 여야한다는 제약 조건을 적용하면 예전 프로그램이 손상 될 수 있습니다.
그것은 당신이에서 LoadLibrary와 함께 DLL을로드하고 인터페이스를 변경하지 않은 경우 예, 당신이 잘되어야 이론적으로
을 따라 달라집니다.
일부 .lib 스텁을 사용하여 .dll 파일과 연결하는 경우 작동한다는 보장은 없습니다.
COM이 발명 된 이유 중 하나입니다.
DLL 인터페이스가 변경되지 않은 한 .lib 스텁을 사용할 때 아무런 문제가 없습니다. COM은 완전히 다른 이유로 발명되었습니다. –
이렇게하면됩니다. DLL에 대한 인터페이스가 동일하게 유지되는 한 오래된 실행 파일은이 파일을로드하여 잘 사용할 수 있습니다. 즉, 당신은 매우 위험한 길을 시작하고있다. 시간이 갈수록 점점 더 많은 DLL에 패치를 적용하면 고객 설치에서 비정상적으로 동작하는 것을 진단하기가 거의 불가능해질 수 있습니다. 이것은 다양한 구성 요소의 서로 다른 버전 간의 예기치 않은 상호 작용으로 인해 발생합니다. 역사적으로이 문제는 DLL 지옥으로 알려져 있습니다.
내 의견으로는 전체 응용 프로그램을 다시 작성하고 다시 테스트하고 재배포하는 것이 좋습니다. 또한 더 나아가 응용 프로그램 매니페스트를 사용하여 실행 파일이 만 특정 버전의 DLL에서 작동 할 수 있도록하는 것이 좋습니다. 지금은 많은 일처럼 보일지 모르지만, 장래에 두통을 많이 줄 수 있습니다.
우리는 몇 달에 한 번씩 소프트웨어의 새 버전을 다시 빌드하고 출시합니다. 그래서 이것은 우리의 다음 풀 릴리즈까지는 정말 일시적인 수정입니다, 그래서 우리는이 경우에 dll을 피할 수 있다고 생각합니다. 모든 것을 대체하는 것보다 사용자 시스템에서 1 dll을 대체하는 것이 훨씬 쉽습니다. –
+1. 또한 그 반대도 약간 까다 롭습니다. 리턴 타입이'int'이고 이전 DLL은 항상 양수 값을 반환하고 EXE 중 하나는 이것을 예상하고 새로운 DLL은 음수 값을 반환 할 수 없습니다. (이전의 DLL 대신 가정에 대해 모든 EXE를 검사해야하기 때문에 어렵습니다.) 이러한 제약 조건은 일반적으로 사전 및 사후 조건으로 알려져 있습니다. – MSalters