답변:
이것은 매우 가능합니다.
다른 어셈블리 (또는 프로젝트 및 추가 된 어셈블리)에서 동일한 네임 스페이스 및 유형 이름을 정의한 경우 이러한 유형 중 하나를 사용하려고하는 코드와 충돌이 발생합니다.
고유 한 네임 스페이스가 있는지 확인하면 참조와 마찬가지로이 문제가 발생하지 않습니다.
또 다른 가능성은 다른 버전의 종속성과 관련이 있습니다. 프로젝트에서 버전 1.2의 로깅 라이브러리를 사용하지만 추가 된 어셈블리가 동일한 어셈블리에 있지만 다른 버전 (1.3)과 프로젝트 중 하나에 의존하는 경우 또는 추가 된 어셈블리가 특정 버전을 사용하도록 구성 / 빌드 된 경우 충돌이 발생하여 빌드가 실패합니다.
여기에 설명 된대로 어셈블리 별명을 사용하여이 문제를 해결할 수 있습니다 .
다른 사람이 이것을 언급하지 않았으므로 다음과 같이 물었습니다.
이것을 완화시키는 가능한 방법은 무엇입니까
이 경우에는 제약이 없으며 성가신 해결 방법이없는 깨끗한 솔루션이 있습니다. 컴파일러가 올바른 위치에서 참조 할 항목을 알 수 있도록 어셈블리 별칭을 정의 할 수 있습니다.
한 번 봐 가지고 http://blogs.msdn.com/b/ansonh/archive/2006/09/27/774692.aspx을
네, 가능합니다.
Lucene.Net의 이전 버전을 사용하는 일부 DLL에 대한 참조를 추가했으며 최신 버전을 포함시키고 싶다고 가정 해 봅시다.
extern 별명을 사용하여 해당 문제점을 해결할 수 있습니다. http://msdn.microsoft.com/en-us/library/ms173212.aspx
강력한 이름을 가진 경우 전역 어셈블리 캐시에 원하는만큼 다른 버전의 어셈블리 를 넣을 수 있습니다 . 다른 응용 프로그램이 다른 버전의 어셈블리를 기계적으로 사용하도록하려는 경우 도움이 될 수 있습니다. 그러나 하나의 응용 프로그램에서 다른 버전의 어셈블리를 사용하면 여전히 문제가 발생합니다.
두 버전을 동시에 필요로하는 이유는 무엇입니까?
확실 해요 두 개체를 구별 할 수없는 경우 "모호한 참조"컴파일러 오류가 발생할 수 있습니다. 일반적으로 코드에서 전체 경로를 지정할 수 있으며 문제가 발생하지 않지만 dll이 완전히 동일한 경우 두 객체를 구분할 수 없습니다. Sya에는 두 개의 dll이 있습니다.
File 클래스를 포함하는 System.IO
과
File 클래스를 포함하는 MyProject.IO
이런 식으로 뭔가를했다면 ...
using System.IO;
using MyProject.IO;
...
private void foo()
{
File f = new File();
}... 어떤 파일을 말하고 있는지 알 수있는 방법이 없으므로 모호한 참조가 필요합니다. 이것은 그것을 고칠 것입니다 :
using System.IO;
using MyProject.IO;
...
private void foo()
{
MyProject.IO.File f = new MyProject.IO.File();
}수정하기 어려운 유일한 방법은 "파일"의 경로가 두 어셈블리 모두에서 동일한 경우이지만 두 dll이 동일한 네임 스페이스 구조를 갖는 경우는 거의 없습니다. 예를 들어, 아무도 .Net 프레임 워크의 실제 개발자를 제외하고 프로젝트 "System"으로 이름을 지정하지 않기 때문에 위의 상황은 결코 일어나지 않을 것입니다.