Я попытался выполнить поиск по ранее заданным вопросам, но их трудно отсеять, потому что кажется, что 99% относятся к проблемам со ссылками после сборки , тогда как моя проблема заключается в проблемах со ссылками после очистки .
Проблема в следующем: я восстанавливаю старый проект, над которым, к сожалению, никогда раньше не работал, и все компилируется и отлично работает, когда я создаю решение.
Однако, когда я использую «Чистое решение», я получаю справочные ошибки для одного проекта. Речь идет о проекте веб-службы Visual Basic. В нем есть ссылка на два других проекта (которые являются C #), и когда я смотрю на свойства проекта, на панели ссылок я вижу, что путь, используемый для ссылки, - это SolutionFolder \ Project \ bin \ Debug \ Projectname.dll.
Поэтому всякий раз, когда я очищаю свое решение, bin \ Debug очищается, а ссылка отсутствует. Означает ли это, что ссылка настроена неправильно?
Изучая проблему, я понял, что ссылки на проекты работают по-разному для проектов VB, но мне кажется странным, что комбинация проектов C # и VB выдает справочные ошибки в тот момент, когда вы очищаете решение.
Может ли кто-нибудь помочь мне / объяснить, почему это происходит?
Хорошо, я сделал шаги, чтобы воссоздать проблему. Это работает следующим образом:
Visual Studio -> Новый проект -> Приложение службы Visual Basic WCF
Решение -> Добавить -> Новый проект -> Библиотека классов C #
В библиотеке классов добавьте следующую функцию
namespace ClassLibrary1
{
public class Class1
{
public static int Foo()
{
return 1;
}
}
}
Проект Visual Basic WCF -> Добавить -> Ссылка -> C # ClassLibrary (из проекта решения)
Построить решение
В Сервисе я меняю функцию GetData следующим образом:
Public Function GetData(ByVal value As Integer) As String Implements IService1.GetData
Dim foo = ClassLibrary1.Class1.Foo
Return String.Format("You entered: {0}", value)
End Function
Построить решение
Теперь чистый раствор.
Visual Studio теперь сообщает мне, что у меня есть справочные ошибки.
Построй снова.
Ошибки исчезли.
4 ответа
Как заявил Маартен, существует важное различие между добавлением ссылки на проект и добавлением ссылка на файл . Я хотел бы объяснить это более подробно - оригинальные кредиты принадлежат Мартену!
Есть совершенно разные способы добавления ссылки в сборку. Подробную информацию можно найти в статье MSDN Как: добавлять или удалять ссылки с помощью диспетчера ссылок .
Как и просил оператор, мы сосредотачиваемся на ссылке на файл и проект. Я покажу, как VS сохраняет эталонные настройки и какое влияние они оказывают на ваш проект! В моем примере я сделал решение с тремя проектами (a, b и c). Проект C относится к A и B.
Ссылка на файл (Обзор)
Как мы видим, ссылка на файл статически относится к файлу на вашем жестком диске. Если указанный файл недоступен, вы получите предупреждение о неработающей ссылке . Поэтому, когда вы очищаете свое решение, все уже созданные сборки будут очищены. По этой причине вы получаете предупреждение.
Ссылка на проект (решение - проект)
Ссылка на проект сохраняет GUID проекта целевой . Таким образом, при сборке текущего проекта VS будет искать целевой проект и также строить его - при необходимости .
Вот почему MSDN заявляет:
Вам следует избегать добавления ссылок на файлы на результаты другого проекта . в том же решении , поскольку эта тактика может вызвать компиляцию ошибки. Вместо этого используйте вкладку «Решение» в диалоговом окне «Диспетчер ссылок». поле для создания межпроектных ссылок. Эта тактика заставляет команду разработка проще, позволяя лучше управлять классом библиотеки, которые вы создаете в своих проектах. Для получения дополнительной информации см. Устранение неполадок с неработающими ссылками.
ИЗМЕНИТЬ
Поскольку ваш проект содержит разные языки , VS не может разрешить ссылку на ваш проект. Вы можете взглянуть на этот аналогичный вопрос SO работает с двумя языками в одном решении. Очевидно, хотя это ссылка на проект, VS обрабатывает ее как ссылку на файл.
В Visual Studio есть несколько языковых служб которые зависят от языка . Таким образом, если вы ссылаетесь из одной сборки C # на другую сборку C #, соответствующие языковые службы будут обрабатывать любые потенциальные ошибки ссылки при создании ссылки на проект.
Но если вы ссылаетесь на сборку VB.net с C # (или наоборот), для этого не существует "межязыковой" службы . Очень простой пример: связанный <summary> tags из сборки C # не будет отображаться в проекте VB.net (как указано в связанном вопросе / комментариях).
Я думаю, что ссылка теперь установлена на физический файл dll в папке bin\debug, а не на проект, который строит этот файл dll.
Если вы установите ссылку на физический файл dll, Visual Studio всегда будет ожидать, что этот файл будет там, а в противном случае будет жаловаться.
Если вы установите ссылку на проект, который создает файл dll, Visual Studio будет смотреть на проект, и он всегда будет там. Visual studio не будет жаловаться на отсутствующий файл dll, поскольку он не интересуется ссылками на файл dll.
Удалите ссылку, которая у вас есть сейчас, и создайте новую ссылку, которая указывает на проект вместо файла dll.
Правильно ли настроены зависимости вашего проекта для этого проекта Visual Basic.
Вы можете указать зависимости, щелкнув правой кнопкой мыши проект в Solution Explorer и выбрав Project Dependencies. Убедитесь, что здесь отмечены два других упомянутых проекта.
Кроме того, можете ли вы проверить, что два ваших проекта, на которые ссылается проект Visual Basic, настроены на сборку в окне Configuration Manager для конфигурации Debug.
Хочу поблагодарить всех за быстрые и четкие ответы.
Я пробовал решения и искал еще несколько, но я не решил проблему и считаю, что этот пост наиболее применим к моей ситуации:
https://stackoverflow.com/a/3989670/3895498