Сохраняющаяся зависимость сборки в C # .NET

Question

Мой проект на C # - назовем его SuperUI - используется для использования класса из внешней сборки. Сейчас это не так, но компилятор не позволит мне собрать проект без ссылки на сборку. Позвольте мне уточнить.

Этот проект использовался для создания и перехвата пользовательского класса исключений - SuperException - который был получен из стандартного System.Exception и находился в отдельной предварительно скомпилированной сборке SuperAssembly.DLL, на которую я ссылался.

В конце концов я решил, что это бессмысленное упражнение, и заменил все SuperExceptions на исключение System.SuitableStandardException в каждом случае. Я удалил ссылку на SuperException.DLL, но теперь при попытке скомпилировать проект встречаю следующее:

Тип 'SuperException' определен в сборке, на которую нет ссылок. Вы должны добавить ссылку на сборку 'SuperException, Version = 1.1.0.0 (...)'

Исходный файл, на который ссылается ошибка, не имеет значения; это пространство имен проекта, которое выделяется в IDE.

Теперь вот что:

1. Все случаи использования SuperException были исключены из кода проекта.
2. По сравнению с другим проектом, который прекрасно компилируется без ссылки на SuperException.DLL, я ссылаюсь только на еще одну сборку - и that не ссылается ни на что, на что мой проект не ссылается сам. Хотя возможно, что любая из этих зависимостей может выдать SuperExceptions, я только ловлю базовый класс Exception и в любом случае ... другой проект работает нормально!
3. Я делал «Чистое решение» для Visual Studio и много раз очищал все вручную.

Это не конец света, чтобы включить эту ссылку, я просто не понимаю, почему это необходимо больше. Nrrrgg. Любые указатели приветствуются!

Answer 1

Вероятно, это транзитивная ссылка, где вызов метода некоторого типа возвращает экземпляр SuperException в штучной упаковке ("downcast"), например Исключением является то, что из проверки кода в транзитивно включенном коде, то есть кода из ваших вызовов внешних методов, компилятор знает, что вам нужно иметь возможность иметь информацию об этом типе в какой-то момент.

Resharper скажет вам, в каком случае вам нужно добавить ссылку, и вы можете использовать Reflector Lütz Roeder, также известный как RedGate, для сканирования скомпилированного IL для ссылки на этот тип двумя способами: 1) использовать средство поиска, 2) откройте каждый открытый тип, который вы используете, и для того, который требует сборки «ghost», он попросит вас указать его местоположение.

Это чаще всего случается со мной, когда я ссылаюсь на Castle.Windsor, но не на Castle.MicroKernel. : Р

Answer 2

Я не думаю, что это проблема кода. Я вижу, что одна из ваших существующих ссылок, вероятно, полагается на этот тип в своих собственных типах, которые вы, вероятно, создаете в своем приложении.

Если это так, вам нужна эта ссылка, даже если вы явно не используете тип, и хотя у другой ссылочной сборки есть собственная ссылка. Иногда возникает проблема со сторонними компонентами, которые нуждаются в ссылках на типы, на которые вы не ссылались. Компилятор, очевидно, видит что-то в одной из ваших существующих сборок, на которые ссылаются, и ожидает, что вы ссылаетесь на зависимую.

Answer 3

Я согласен с другими комментариями здесь .. Есть ссылка, в виде простого текста где-то ! У меня были подобные проблемы в прошлом, когда поиск по файлам проекта ничего не возвращал, оказалось, что это был какой-то другой файл, который не был автоматически обнаружен при поиске.

Я не думаю, что создание нового проекта является решением здесь .. Вы должны быть уверены, что НЕТ ссылок в вашем дереве зависимостей используют SuperException .. НЕТ

Я никогда не испытывал это до такой степени, что мне нужно было буквально стереть проект, я всегда где-то находил ссылку. Убедитесь, что вы ищете каждый файл.

EDIT:

Просто добавление, если местоположение, на которое указывает ошибка, кажется случайным, это часто может означать несоответствие между скомпилированным исходным кодом и файлом исходного кода. Является ли это приложением ASP.NET? У меня было это раньше, когда скомпилированные DLL не были заменены при перекомпоновке во временную папку ASP.NET, что привело к получению вещей .. Интересно при отладке:)

Answer 4

1. Выход из Visual Studio
2. Удалите папки bin и obj в вашем каталоге решений
3. Перезагрузите компьютер и посмотрите, что произойдет

Answer 5

В настоящее время нет ничего особенно таинственного в проектах VS - все это текстовые файлы и т. Д. ЧТО-ТО должно ссылаться на этот класс / dll, и что-то должно быть частью вашего проекта.

Вы действительно grep'd или findstr'd все дерево решений, каждый файл , для ссылки на это исключение?

Answer 6

Спасибо за ваши ответы. Я попробовал каждое предложение (кроме одного) безрезультатно.

Я не пробовал создать новый проект и добавить в него все свои вещи, мысль о которых действительно проверяет мое желание жить. ;) Я могу попробовать это завтра, если я буду обеспокоен. Еще раз спасибо.

Answer 7

Поскольку это ошибка компилятора, в проекте должна быть ссылка или использование SuperException.

1. Выполните поиск / замену во всем проекте или решении для этого типа и удалите все ссылки (возможно, вы уже сделали это).
2. Если вы ссылаетесь на любые типы, которые наследуются от SuperException (даже если тип определен в другой сборке), вам нужна ссылка на сборку, в которой определено SuperException.

Возьмите строку, на которой компилятор отображает ошибку, и начните отслеживать дерево наследования объектов, используемых в этой строке, вы можете найти его источник таким образом.

Answer 8

У меня была очень похожая проблема со ссылкой на сборку, которая возникала, когда моя библиотека C # имела зависимую сборку C ++ / CLI. Проблема в том, что я унаследовал открытый класс от той сборки C ++ / CLI в моей библиотеке сборки C #. Это означало, что цепочка наследования охватила несколько сборок.

Я надеялся, что любой клиент будет достаточно умен, чтобы косвенно загружать сборку C ++ / CLI в любое время, когда это понадобится библиотеке C #, но это было не так даже во время компиляции.

Я избавился от этой проблемы, нарушив наследование между классами, охватывающими эти две библиотеки сборок, и вместо этого использовал агрегирование. Мой клиент был наконец доволен и больше не требовал сборки C ++ / CLI в качестве зависимости.

Словом, вам, вероятно, придется убедиться, что SuitableStandardException не наследуется от SuperException, чтобы исключить SuperException.DLL в качестве ссылки.

Используйте инкапсуляцию вместо наследования и создайте элемент данных SuperException в своем новом SuitableStandardException.

Если это не решит проблему, у вас может быть больше классов, охватывающих наследование в некоторых сборках, в вашем случае SuperAssembly.DLL и superException.dll.

Если вы не можете найти их всех, попробуйте этот трюк:

1. Сделайте все ваши публичные члены и классы во SuperAssembly.DLL внутреннем.

2. В SuperAssembly.DLL подружитесь с SuperException.DLL:

   [assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]
   

3. Убедитесь, что они создают и удаляют ссылку SuperAssembly.DLL из любого клиента, который уже ссылается на SuperException.DLL.

Answer 9

Именно здесь такие инструменты, как Resharper , действительно окупаются - простое использование поиска обычно говорит мне о таких "призрачных зависимостях" несколько раз.

Возможно, вы можете перейти к определению класса SuperException и попытаться найти все ссылки (). Возможно, вы также захотите выяснить, имеет ли сборка SuperException круговую зависимость от вашей основной сборки (например, основная сборка зависит от сборки исключений, зависит от основной сборки ...).

Answer 10

grep -R SuperException * в основе вашего проекта (сначала получите grep откуда-то), просто чтобы быть уверенным.