Произвольная ссылка на сборку завершается неудачно ("Вам не хватает директивы using или ссылки на сборку?")
Мое приложение имеет набор из 3,5 и 4,0 целевых сборок. Я работаю над новой службой Windows, нацеленной на 4.0, и проект внезапно оказывается не в состоянии увидеть некоторые другие сборки в решении. Это означает, что при сборке все ссылки на эти другие сборки приводят к следующей ошибке:
Тип или имя пространства имен "[X]" не существует в пространстве имен "[Y]" (отсутствует ссылка на сборку?)
Если я удаляю ссылку на проект и снова добавляю ее, красные кривые исчезают, а Intellisense включается снова, как и положено. Все остальные проекты в решении строятся без проблем. Но как только я пытаюсь построить этот новый проект, ошибки возвращаются.
Одна из ошибочных ссылок относится к нашему Core.dll, который нацелен на 3.5. Недавно мы добавили CoreEx.dll, ориентированный на 4.0, с общим пространством имен между сборками. Новый сервис может видеть CoreEx.dll, но не Core.dll... т.е. когда я начинаю печатать using Core.Utilities...
Intellisense обнаруживает меньший набор пространств имен из CoreEx.dll, но не показывает ни одного, который появляется только в Core.dll. Я почти уверен, что решение было успешно построено после добавления этого, но это заметное недавнее изменение.
Еще одна недостоверная ссылка на наш основной Data.dll, который содержит наборы данных и прочее Entity Framework. Этот был недавно перенесен в 4.0. Опять же, я почти уверен, что решение, созданное после переноса проекта, стоит упомянуть.
Последней ошибочной ссылкой является сборка, которая использует пространство имен на один уровень выше от сервиса. Например, проблемный проект основан на пространстве имен ProductName.Component.ComponentService
и он не может видеть проект, основанный на пространстве имен ProductName.Component
, Этот был недавно создан вместе с проблемным проектом и также нацелен на 4.0.
Как вы можете видеть, кажется, что не существует какой-либо рифмы или причины, по которой ссылки на сборки не работают... и проблемный проект может успешно ссылаться на некоторые другие сборки в решении. Я пытался очистить, перестроить, перезапустить Visual Studio... ничто не исправило это навсегда. Что может быть причиной этого?
7 ответов
Проверьте целевую платформу нового проекта и убедитесь, что он не нацелен на.NET 4 Client Profile. Если это так, измените его на обычный.NET 4
Я добавлял проекты в решение, которое использовало.net 4.5. Проекты, которые я добавил, были по умолчанию 4.5.1. Это сделало 4,5 библиотеки несовместимыми с новыми проектами. Я вошел в свойства моих новых проектов и поставил им цель 4.5 вместо 4.5.1 по умолчанию. После того, как я это сделал, мое решение смогло построить.
Правильно ли установлены зависимости в решении? Я видел не один случай, когда Проект A зависит от Проекта B, но из-за того, что зависимость между ними не была установлена, сборка время от времени терпит неудачу.
Основная причина в этом случае заключается в том, что порядок сборки не является детерминированным, а успех / неудача зависит от таких вещей, как какие проекты строятся (в зависимости от того, что изменилось) и какие строятся первыми (когда выполняется более одной сборки).
Эта проблема возникла у меня, когда я решил ее, удалив все операторы использования сверху и снова записав их вручную.
У меня была похожая проблема: ошибка ссылки на сборку ("Вы пропустили директиву использования или ссылку на сборку?"), И VS intellisense дал мне возможность добавить использование, но в решении ссылка имела желтый значок и сборку терпел неудачу.
Я решил это, взглянув на свойство проекта Target Framework и изменив версию.net на версию эталонного решения, и это решило все проблемы.
Примечание. Версии.net должны быть совместимы между проектами.
Также обратите внимание, что это может произойти, если вы измените пространство имен, но вы не изменили имя сборки в свойствах проекта.
Это сработало для меня, когда я изменил целевой фреймворк на 4.0. Но это было не то решение, которое мы хотели. Мы хотели использовать VS 2010 Premium для нашего проекта, но не собирались использовать.net 4.0... Основной класс проект библиотеки (.net 2.0) ссылался на dll "system.web.abstractions.dll"... я добавил ссылку на эту dll в других проектах (.net 2.0), которая ссылается на библиотеку основного класса... решение скомпилировано без проблем... так может быть и с вашим решением для визуальной студии...
Но все работает нормально, если мы используем VS 2008 professional.. нам не нужно обходиться стороной, и все работает как по волшебству...