우리가 .NET에서 응용 프로그램을 개발할 때 우리는 개발 끝에 설치를 만들고 클라이언트에게 설치를 보냅니다. 클라이언트가 설치 파일을 설치하십시오.DotNet의 패치 개발
우리의 코드를 변경하거나 우리의 애플 리케이션에 새로운 기능을 추가하면 우리는 다시 설치 프로그램을 만들고 다시 설치하도록 클라이언트를 돌려줍니다. 이 시나리오에서 설치 파일 크기가 커지면 패치와 같은 방법으로 코드를 변경하면 패치를 만들어 클라이언트에 제공 할 수 있습니까?
클라이언트가 해당 패치를 설치하고 변경 사항을 적용하고 이전 기능이 응용 프로그램에서 그대로 유지됩니다. 그래서 어떻게 패치를 사용하여 새로 추가 된 유일한 기능을 제공하거나 클라이언트의 일부만 클라이언트로 변경할 수 있습니까?
매우 가벼운 무게이기 때문에 이러한 종류의 설정 개발을 구현하기위한 모든 단계를 자세하게 설명하십시오.
감사
하나의 간단한 방법은 (당신이 코드 서명 또는 어셈블리를 난독 특히 경우) 별도의 어셈블리 (DLL을)의 번호로 응용 프로그램을 중단하는 것입니다. 그런 다음 코드를 업데이트하면 실제로 변경된 어셈블리 만 배포하면됩니다.
가장 중요한 것은 종속성을 제어하는 것입니다. 처음부터 어셈블리 사이의 인터페이스를 잘 정의하고 기존 인터페이스를 "기존 변경 사항"을 변경하는 대신 기존 기능을 확장하는 새로운 인터페이스를 추가하여 추가 할 수 있습니다. 패치에 많은 어셈블리를 배포하지 않고도 응용 프로그램을 유용하게 변경할 수 있습니다. (많은 의존성이있는 경우 어디에서든지 변경 작업을 수행하면 거의 모든 어셈블리를 고객에게 배포해야하므로 목적을 다소 벗어날 수 있습니다.
이 접근법은 가능한 가장 컴팩트 한 패치를 제공하지는 못하지만 매우 간단하고 구현하기 쉽습니다. 그리고 많은 경우 "허용 가능한 정도로 작은"패치를 제공 할 수 있습니다. 또한 개발자는 최소한의 의존성으로 우수한 모듈 식 디자인을 사용하는 것에 대해 열심히 생각하도록 권장합니다. 따라서 더 정교한 패치 메커니즘을 맨 위에 추가하더라도 (이유가 있다면) 가치가 있습니다.
패치 방법을 사용하는 경우 주기적으로 고객에게 정식 버전을 제공하는 것이 좋습니다. 적용 할 패치가 많을수록 무언가가 동기화되지 않을 위험이 커집니다. (Windows Update 작동 방식 고려 - OS가 패치로 점진적으로 업데이트되지만 모든 소형 패치를 하나의 큰 패치로 만드는 서비스 팩을 발행 할 때마다 새로운 버전의 운영 체제를 출시하는 빈도가 줄어 듭니다. 사용자는 처음부터 다시 설치해야 함)