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

Мой проект на 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. Любые указатели приветствуются!

12.08.2008 19:35:44
14 ОТВЕТОВ
РЕШЕНИЕ

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

Решарпер скажет вам, в каком случае вам нужно добавить ссылку, и вы можете использовать рефлексор Лютца Рёдера или RedGate для сканирования скомпилированного IL на наличие ссылки на этот тип двумя способами: 1) использовать средство поиска, 2) открыть каждый публичный тип, который вы используете, и для того, который требует сборки «ghost», он попросит вас указать его местоположение.

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

3
18.02.2009 02:23:00

Это звучит довольно странно. Вот что я бы проверил дальше:

  1. Убедитесь, что в вашем файле Properties / AssemblyInfo.cs ничего не осталось.
  2. Убедитесь, что в вашем файле SuperUI.csproj ничего не осталось.
  3. Удалите все ссылки и повторно добавьте их.
0
12.08.2008 19:46:51

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

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

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

1
12.08.2008 19:48:52

Попробуйте создать новый проект и добавить в него все свои классы.

0
12.08.2008 19:51:10
  1. Выход из Visual Studio
  2. Удалите папки bin и obj в вашем каталоге решений
  3. Перезагрузите и посмотрите, что происходит
2
12.08.2008 20:01:59

grep папка вашего проекта. Это может быть скрытая ссылка в вашем проекте или проект, на который ссылается ваш проект. Очистите с помощью блокнота, если это необходимо.

0
12.08.2008 20:06:20

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

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

1
12.08.2008 20:38:39

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

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

1
12.08.2008 20:46:22

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

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

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

РЕДАКТИРОВАТЬ:

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

2
12.08.2008 21:41:46

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

С этим согласился.

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

Попробуй взломать с пробной версией NDepend

0
12.08.2008 21:49:16

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

-1
13.08.2008 00:29:42

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

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

0
13.08.2008 01:05:29

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

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

2
21.08.2008 14:11:02
Попробуйте поискать в других сборках, на которые есть ссылки, SuperException с помощью Reflector, чтобы убедиться, что они не ссылаются на сборку.
cstick 18.02.2009 02:51:09

У меня была очень похожая проблема со ссылкой на сборку, которая возникала, когда моя библиотека 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.

0
4.12.2012 08:21:12