Chociaż mam konkretny przypadek, ale zastanawiałem się nad ogólną sytuacją.
Czy dwie biblioteki DLL, dodane jako Odniesienie do projektu Visual C #, mogą kolidować ze sobą, aby zapobiec tworzeniu rozwiązania? Jeśli tak jest, jakie są możliwe sposoby złagodzenia tego.
Odpowiedzi:
To bardzo możliwe.
Jeśli zdefiniowałeś identyczną przestrzeń nazw i wpisz nazwę dla różnych zestawów (lub w swoim projekcie i dodanym zestawie), wystąpi konflikt z dowolnym kodem, który próbuje użyć jednego lub drugiego z tych typów.
Jeśli upewnisz się, że masz unikalne przestrzenie nazw, podobnie jak odniesienia, nie miałbyś tego problemu.
Inna możliwość wiąże się z różnymi wersjami zależności - jeśli twój projekt używa (na przykład) biblioteki rejestrowania w wersji 1.2, ale dodany zestaw ma zależność od tego samego zestawu, ale innej wersji (powiedzmy 1.3) i albo twojego projektu lub dodany zestaw został skonfigurowany / zbudowany do używania określonej wersji, pojawi się konflikt i kompilacja zakończy się niepowodzeniem.
Oba te problemy można rozwiązać za pomocą aliasów zespołu, jak opisano tutaj .
Ponieważ nikt o tym nie wspominał, zapytałeś:
jakie są możliwe sposoby złagodzenia tego
Dla tego przypadku istnieje czyste rozwiązanie, bez ograniczeń i bez irytujących obejść. Można zdefiniować aliasy zestawu, aby kompilator wiedział, do których należy się odwoływać we właściwym miejscu.
Zajrzyj na http://blogs.msdn.com/b/ansonh/archive/2006/09/27/774692.aspx
Tak, to bardzo możliwe.
Załóżmy, że dodałeś odwołanie do biblioteki DLL korzystającej ze starej wersji Lucene.Net i chcesz dołączyć najnowszą wersję.
Możesz rozwiązać ten problem, używając zewnętrznych aliasów: http://msdn.microsoft.com/en-us/library/ms173212.aspx
Możesz umieścić dowolną liczbę różnych wersji zestawu w globalnej pamięci podręcznej zestawów pod warunkiem, że mają one silną nazwę. Może to ci pomóc, jeśli chcesz, aby różne aplikacje korzystały z różnych wersji zestawu, jeśli chodzi o maszynę. Jednak używanie różnych wersji zestawu w JEDNEJ aplikacji nadal będzie sprawiało kłopoty.
Jaki jest powód, dla którego potrzebujesz obu wersji jednocześnie?
Na pewno. Błąd kompilatora „Niejednoznaczne odniesienie” można uzyskać, gdy nie można rozróżnić dwóch obiektów. Zazwyczaj można podać pełną ścieżkę w kodzie i nie spowoduje to problemu, ale jeśli biblioteki dll byłyby w pełni identyczne, nie można w żaden sposób rozróżnić dwóch obiektów. Sya, mamy dwie biblioteki dll:
System.IO, który zawiera klasę File
i
MyProject.IO, który zawiera klasę pliku
Gdybyś miał mieć coś takiego ...
using System.IO;
using MyProject.IO;
...
private void foo()
{
File f = new File();
}... miałbyś dwuznaczne odniesienie, ponieważ nie ma sposobu, aby powiedzieć, o którym pliku mówisz. Naprawiłoby to:
using System.IO;
using MyProject.IO;
...
private void foo()
{
MyProject.IO.File f = new MyProject.IO.File();
}Jedyny sposób, w jaki trudno byłoby to naprawić, byłby gdyby ścieżka pliku była identyczna w obu zestawach, ale wymagałoby to nieprawdopodobnej sytuacji, w której dwie biblioteki dll miały identyczną strukturę przestrzeni nazw. Na przykład moja powyższa sytuacja nigdy by się nie wydarzyła, ponieważ nikt nie nazwie tam projektu „System” (z wyjątkiem faktycznych programistów frameworku .Net).