.NET BINIRAL (DLL) 인터페이스를 깨는 것

Question

두 개의 .NET DLL을 고려하십시오. 첫 번째 "Application.dll"에는 기본 비즈니스 로직 및 데이터 액세스 코드가 포함되어 있습니다. 두 번째, "webservice.dll"은 WebService 호출을 기존 코드에 제공하기 위해 Application.dll을 사용하여 개체 및 메소드에 링크하는 대부분의 웹 메드로 구성됩니다.

어떤 변경 사항 (예 : 새 클래스 추가, 기존 클래스에 새 필드 또는 메소드를 추가) WebService.dll의 재 컴파일이 필요하지 않고 Application.dll에 만들 수 없습니까?

Answer 1

대부분의 것들은 괜찮을 것입니다. 그것을 깨뜨릴 몇 가지 :

• 제거* 사용되는 유형 (유형 포워드를 사용하지 않는 한)
• 제거* 사용되는 방법 (생성자 포함)
• 메소드의 서명 변경 (사용되는)
• 공공 분야 변경 속성 (사용되는)
• 직렬화 변경 내부화를 사용하는 경우
• 두 번째 DLL에 인터페이스를 구현하는 유형이있는 인터페이스에 메소드 추가
• 두 번째 DLL에 상속 된 기본 클래스에 추상 방법을 추가
• Hacky Reflection이 (AB) 사용되는 경우 거의 모든 내부
• 일반 유형/방법에 제약 조건을 추가합니다
• 유형을대로 표시합니다 sealed 두 번째 DLL에 상속 될 때
• a에 필드를 추가합니다 struct 발신자가 생성자 초기화보다는 멤버 께 초기화를 사용하는 경우

(제거에는 비공개로 접근성 변경이 포함됩니다)

Answer 2

기술적으로 이름은 이름과 버전 및 강력한 이름의 어셈블리의 경우 키 토큰을 깨뜨릴 것입니다. 그렇지 않으면 프레임 워크가됩니다 노력하다 DLL을로드하고 사용하려면 다른 유형 또는 메소드 서명, 누락 된 유형 등에 도달 할 때까지 다소 잘 작동합니다. 그).

더 많이 읽는 것이 좋습니다 어셈블리 버전화 그러한 문제를 해결하는 방법을 알기 위해.

Answer 3

새 클래스를 호출하지 않는 한 WebService.dll을 다시 컴파일하지 않고 Application.dll을 변경할 수 있습니다. WebService.dll에서 application.dll 변경을 원하시면 WebService.dll을 다시 컴파일해야합니다.

물론, webrvice.dll에서 사용하는 Application.dll의 메소드 또는 속성의 서명 또는 액세스 레벨을 변경하면 WebService에서 코드를 중단합니다.