Может ли кто-нибудь объяснить следующее поведение?CLSCompliant (true) перетаскивает неиспользованные ссылки
Таким образом, если вы создаете несколько CLS-совместимые библиотек в Visual Studio 2008 и у них имеет общий корень пространства имен, библиотека ссылок другую библиотеки будет требует ссылки на ссылки этой библиотеки, даже если она не потребляет их.
Это довольно трудно объяснить в одном предложении, но вот шаги, чтобы воспроизвести поведение (обратите пристальное внимание на пространствах имен):
Создать библиотеку под названием LibraryA и добавить аа один класс в этой библиотеке:
namespace Ploeh
{
public abstract class Class1InLibraryA
{
}
}
Убедитесь, что библиотека совместима с CLS, добавив [assembly: CLSCompliant(true)] в AssemblyInfo.cs.
Создайте еще одну библиотеку под названием LibraryB и reference LibraryA. Добавьте следующие классы библиотека B:
namespace Ploeh.Samples
{
public class Class1InLibraryB : Class1InLibraryA
{
}
}
и
namespace Ploeh.Samples
{
public abstract class Class2InLibraryB
{
}
}
Убедитесь, что также библиотека B CLS Compliant.
Обратите внимание, что Class1InLibraryB происходит от типа библиотеки, тогда как Class2InLibraryB этого не делает.
Теперь создайте третью библиотеку под названием LibraryC и ссылку LibraryB (но не LibraryA). Добавьте следующий класс:
namespace Ploeh.Samples.LibraryC
{
public class Class1InLibraryC : Class2InLibraryB
{
}
}
Это все еще необходимо скомпилировать. Обратите внимание, что Class1InLibraryC происходит от класса в LibraryB, что не использует какие-либо типы из LibraryA.
Также обратите внимание, что Class1InLibraryC определяется в пространстве имен, которое является частью иерархии пространства имен, определенной в LibraryB.
До сих пор LibraryC не имеет ссылки на LibraryA, и поскольку он не использует никаких типов из библиотекиA, решение компилируется.
Теперь совместим с библиотекой CL CLS. Внезапно решение больше не компилируется, и вы получите это сообщение об ошибке:
Тип «Ploeh.Class1InLibraryA» определен в сборке, на которую не ссылаются. Вы должны добавить ссылку на сборку 'Ploeh, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = null'.
Вы можете сделать решение составить снова в одном из следующих способов:
- Удалить ЦБС Compliance от LibraryC
- Добавить ссылку на LibraryA (хотя это не нужно)
- Измените пространство имен в LibraryC так, чтобы оно не было частью иерархии пространства имен LibraryB (например, для Fnaah.Samples.LibraryC)
- Изменить пространство имен Class1InLibraryB (то есть, один не используется от LibracyC), так что она не лежит в иерархии пространства имен LibraryC (например в Ploeh.Samples.LibraryB)
Это кажется, что существует некоторая странная взаимосвязь между иерархией пространства имен и соблюдением CLS.
Решение этой проблемы может быть выполнено путем выбора одного из вариантов в приведенном выше списке, но может ли кто-нибудь объяснить причину за этим поведением?
+1 Я тоже это заметил, но не успел открыть вопрос. – Jehof
Очень интересно. Я никогда не сталкивался с этим, потому что я никогда не использовал одно и то же пространство имен в двух проектах библиотеки классов. – RichardOD
Ударьте его тоже, и [открыл вопрос] (http://stackoverflow.com/q/24700730) независимо, прежде чем, наконец, обнаружив это. Я [подал ошибку] (https://connect.microsoft.com/VisualStudio/feedback/details/920175/cls-compliance-and-build-time-transitive-dependency-requirements), как было предложено в другом вопросе. Если у вас есть какие-либо новые материалы по этому вопросу, мне тоже будет интересно. – tne