Дополнительные зависимости visual studio 2019
Обновлено: 04.07.2024
В С++ вы получили файлы заголовков (.h), файлы (.lib) и файлы (.dll).
В Visual Studio вы предоставляете местоположение для поиска этих файлов в трех разных местах:
Свойства конфигурации = > C/С++ = > Общие = > Дополнительные каталоги Include. Здесь вы перечисляете каталоги "включите", которые хотите найти и сделать доступными.
Свойства конфигурации = > Linker = > Общие = > Дополнительные каталоги библиотек. Здесь вы перечисляете каталоги "lib", которые хотите найти и сделать доступными.
Свойства конфигурации = > Linker = > Input = > Дополнительные зависимости. Здесь вы явно указываете файлы .lib, которые хотите включить.
ОТВЕТЫ
Ответ 1
- Свойства конфигурации = > C/С++ = > Общие = > Дополнительные каталоги Include. Здесь вы перечисляете каталоги "включите", которые хотите найти и сделать доступными.
Это говорит компилятору, где искать заголовочные файлы, заключенные в угловые скобки. Это влияет на то, как компилятор (или препроцессор) выполняет эту работу.
- Свойства конфигурации = > Linker = > Общие = > Дополнительные каталоги библиотек. Здесь вы перечисляете каталоги "lib", которые хотите найти и сделать доступными.
Это говорит компоновщику, где искать библиотеки (то есть, какие каталоги искать). Это влияет на то, как выполняет компоновщик (а не компилятор).
- Свойства конфигурации = > Linker = > Input = > Дополнительные зависимости. Здесь вы явно указываете файлы .lib, которые хотите включить.
Это говорит компоновщику, какие библиотеки искать в этих каталогах. Это также влияет на то, как компоновщик выполняет свою работу.
Q1: Обычно, если вы используете 2, вам почти наверняка нужно использовать 3. 3 сообщает, с какой библиотекой связывается, и 2 сообщает, где найти эту библиотеку. Конечно, это может быть более чем одна библиотека.
Q2: Если предоставляется библиотека отладки и выпуска, вы обычно хотите использовать отладочную версию в сборке отладки и версию выпуска в сборке выпуска. В левом верхнем углу диалога вы выбираете, какую конфигурацию вы хотите изменить. Как правило, вы хотите указать каталоги для debug и release, но укажите отдельные библиотеки, один для debug и один для выпуска.
Ответ 2
И просто чтобы указать на очевидное, вам не нужно добавлять какие-либо файлы .h, которые вы используете в настройках свойств вашего проекта, потому что вы явно включаете их в свой исходный код, который ищет заголовки на путях вы уже предоставили.
Ответ 3
Итак, у меня есть ($ DXSDK_DIR)\Lib\x86 и ($ DXSDK_DIR)\Lib\x64, который также устраняет проблему при переходе между 32-битной и 64-битной ОС Windows для разработки.
Ответ 4
Относительно вашего Q2.
Для сторонних библиотек я использую макрокоманды Visual Studio Build Command $(Platform) и $(Configuration) , чтобы ввести что-то вроде этого:
Таким образом, вы можете просто ввести одну и ту же точную строку, а Visual Studio заменить макрокоманды и посмотреть в \cryptopp561\Win32\Output\Release\ или \cryptopp561\Win32\Output\Debug\ в зависимости от того, какая конфигурация у вас активна. Это на самом деле не экономит много набрав, но помогает сохранить согласованность и точность.
Опишите архитектуру приложения на высоком уровне, создав схемы зависимостей в Visual Studio. Убедитесь, что код остается согласованным с этим дизайном, проверив код с помощью схемы зависимостей. В процесс сборки также можно включить проверку слоев. См. видео Channel 9: проектирование и проверка архитектуры с помощью схем зависимостей.
Чтобы узнать, какие выпуски Visual Studio поддерживают эту функцию, см. раздел Поддержка инструментов моделирования и архитектуры в различных выпусках.
Что такое схема зависимостей?
Как и в традиционной схеме архитектуры, схема зависимостей определяет основные компоненты и функциональные единицы проектирования и их взаимозависимости. Каждый узел на схеме, называемый слоем, представляет логическую группу пространств имен, проектов или других артефактов. Можно нарисовать зависимости для своей разработки. В отличие от традиционной схемы архитектуры, можно проверить, соответствуют ли действительные зависимости заданным вами предполагаемым зависимостям. Делая проверку частью стандартного построения в Team Foundation Server, можно добиться того, чтобы программный код продолжал придерживаться архитектуры системы при дальнейших изменениях. См. раздел схемы зависимостей: Справочник.
Разработка и обновление приложений с помощью схем зависимостей
Следующие шаги позволяют получить общие сведения об использовании схем зависимостей в процессе разработки. Каждый шаг более подробно описан в последующих подразделах данного раздела. Если ведется разработка нового проекта, можно пропустить шаги, которые относятся к существующему коду.
Эти шаги приведены в примерном порядке. Возможно, понадобится перекрыть задачи, заново упорядочить их, чтобы они подходили по ситуации, а также возвратиться к ним в начале каждой итерации в проекте.
Создайте схему зависимостей для всего приложения или для слоя внутри него.
Определите слои, представляющие основные функциональные области или компоненты приложения. Дайте этим слоям имена согласно их функциям, например "Презентация" или "Службы". если у вас есть Visual Studio решение, каждый слой можно связать с коллекцией артефактов, такими как проекты, пространства имен, файлы и т. д.
Измените слои и зависимости , чтобы показать обновленный проект, который должен отражаться в коде.
Разрабатывать новые области приложения можно путем создания слоев, представляющих основные архитектурные блоки или компоненты и определяющие зависимости, чтобы продемонстрировать, как каждый из уровней использует другие.
Измените макет и внешний вид диаграммы , чтобы помочь вам обсудить ее с коллегами.
Проверьте код на соответствие схеме зависимостей , чтобы выделить конфликты между кодом и необходимой архитектурой.
Обновите код, чтобы он соответствовал новой архитектуре. Итерационно разрабатывайте и оптимизируйте код до тех пор, пока проверка не укажет, что конфликты отсутствуют.
Включите проверку слоев в процессе сборки , чтобы код продолжал соответствовать вашей структуре.
Создание схемы зависимостей
Схема зависимостей должна быть создана внутри проекта моделирования. Новую диаграмму зависимостей можно добавить в существующий проект моделирования, создать проект моделирования для схемы зависимостей или скопировать существующую диаграмму зависимостей в тот же проект моделирования.
Не добавляйте, не перетаскивайте и не копируйте существующую схему зависимостей из проекта моделирования в другой проект моделирования или в другое расположение в решении. Схема зависимостей, скопированная таким образом, будет иметь те же ссылки, что и исходная диаграмма, даже при изменении схемы. Это может привести к тому, что проверка схемы будет работать неправильно, а также к другим потенциальным проблемам, таким как отсутствующие элементы или другие ошибки при попытке открыть схему.
Определение слоев для представления функциональных областей или компонентов
Рекомендуется называть слои согласно их функциям, например "Презентация" или "Службы". Если артефакты тесно взаимосвязаны, поместите их в один слой. Если артефакты могут быть обновлены отдельно или использованы в разных приложениях, поместите их на разные слои.
Существуют определенные типы артефактов, которые можно связать с слоями, но не поддерживают проверку схемы зависимостей. Чтобы проверить, поддерживает ли артефакт проверку, откройте Обозреватель слоев , чтобы просмотреть свойство Поддержка проверки в ссылке артефакт. См. раздел Обнаружение существующих зависимостей между слоями.
При обновлении незнакомого приложения можно также создать карты кода. Они помогают обнаружить закономерности и зависимости при анализе кода. Воспользуйтесь обозревателем решений, чтобы изучить пространства имен и классы, которые часто находятся в точном соответствии с существующими слоями. Назначьте эти артефакты кода слоям, перетащив их из обозреватель решений в схемы зависимостей. Затем можно использовать схемы зависимостей, которые помогут обновить код и обеспечить его соответствие дизайну.
Обнаружение существующих зависимостей между слоями
Зависимости существуют там, где артефакт, связанный с одним слоем, ссылается на артефакт, связанный с другим слоем. Например, класс в одном слое объявляет переменную, которая имеет класс в другом слое. Существующие зависимости можно обнаружить путем их реконструирования.
Для определенных видов артефактов реконструировать зависимости невозможно. Например, зависимости не могут быть реконструированы из или в слой, связанный с текстовым файлом. Чтобы узнать, какие артефакты имеют зависимости, которые можно реконструировать, щелкните правой кнопкой мыши один или несколько слоев и выберите команду Просмотреть ссылки. В обозревателе слоев изучите столбец поддерживает проверку . Зависимости не будут реконструированы для артефактов, для которых в этом столбце указано значение false.
Чтобы выполнить реконструирование существующих зависимостей между слоями
Выберите один или несколько слоев, щелкните правой кнопкой мыши выбранный слой и выберите команду создать зависимости.
Как правило, на этом этапе можно увидеть некоторые зависимости, которых быть не должно. Эти зависимости можно изменить для соответствия предполагаемой структуре.
Изменение слоев и зависимостей для отображения предполагаемого дизайна
Чтобы описать изменения, которые вы планируете внести в систему или предполагаемую архитектуру, выполните следующие действия, чтобы изменить схему зависимостей. Можно также сделать некоторые оптимизационные изменения для улучшения структуры кода перед его расширением. См. раздел улучшение структуры кода.
Улучшение структуры кода
Оптимизация изменений — это улучшения, которые не влияют на поведение приложения, но помогают сделать код более легким для изменения или расширения в будущем. Хорошо структурированный код имеет конструкцию, легко абстрактную на схеме зависимостей.
Например, если создается слой для каждого пространства имен в коде и затем разбираются зависимости, то необходимо, чтобы был минимальный набор односторонних зависимостей между слоями. Если создается более детальная схема с использованием классов или методов в качестве слоев, то результат должен иметь такие же характеристики.
Если это не так, код будет труднее изменять на протяжении его жизненного цикла и будет менее пригоден для проверки с использованием схем зависимостей.
Разработка новых областей приложения
При начале разработки нового проекта или новой области в новом проекте, можно нарисовать слои и зависимости, чтобы облегчить определение основных компонентов перед началом разработки кода.
По возможности Продемонстрируйте идентифицируемые архитектурные шаблоны на схемах зависимостей. Например, схема зависимостей, описывающая классическое приложение, может включать такие слои, как презентация, логика домена и хранилище данных. Схема зависимостей, охватывающая одну функцию в приложении, может иметь такие слои, как модель, представление и контроллер.
Создайте артефакт кода для каждого слоя , такого как пространство имен, класс или компонент. Это облегчит отслеживание кода и поможет связывать артефакты кода со слоями. Сразу после создания артефакта свяжите его с соответствующим слоем.
Нет необходимости связывать большинство классов и других артефактов с слоями , так как они попадают в более крупные артефакты, такие как пространства имен, которые уже связаны с слоями.
Создайте новую диаграмму для новой функции. Как правило, существует одна или несколько схем зависимости, описывающих все приложение. Если вы разрабатываете новую возможность в приложении, то не добавляйте и не изменяйте существующие схемы. Вместо этого создайте свою схему, которая отражает новые части кода. Слои в новой схеме могут включать в себя презентацию, доменную логику и слои базы данных для новой возможности.
При построении приложения код будет проверяться как в отношении всей схемы , так и в отношении более детальной схемы возможности.
Изменение макета для представления и обсуждения
Чтобы облегчить определение слоев и зависимостей или обсудить их с членами команды, измените вид и разметку схемы следующим образом.
Измените размеры, формы и положение слоев.
Измените цвета слоев и зависимостей.
- Выберите один или несколько слоев или зависимостей, щелкните правой кнопкой мыши и выберите пункт Свойства. В окне Свойства измените свойство Color .
Проверка кода на соответствие схеме
После изменения схемы ее можно проверить на соответствие коду вручную в любое время или автоматически при каждой сборке.
Обновление кода для соответствия новой архитектуре
Как правило, ошибки появляются при первой проверке кода на соответствие обновленной схеме зависимостей. Ошибки могут возникать вследствие нескольких причин.
Артефакт назначен неправильному слою. В этом случае следует переместить артефакт.
Способ использования артефактом (например, классом) другого класса конфликтует с имеющейся архитектурой. В этом случае необходимо выполнить рефакторинг кода, чтобы устранить зависимость.
Для устранения этих ошибок следует обновлять код до тех пор, пока в процессе проверки не перестанут происходить ошибки. Обычно это итерационный процесс. Дополнительные сведения об этих ошибках см. в разделе Проверка кода с помощью схем зависимостей.
При разработке или реструктуризации кода у вас могут быть новые артефакты для связи с диаграммой зависимостей. Однако это может не потребоваться, например, когда слои представляют собой существующие пространства имен, а новый код только добавляет больше материала для них.
В процессе разработки может понадобиться подавить некоторые конфликты, выявленные в ходе проверки. Например, можно подавлять ошибки, над которыми уже ведется работа, а также ошибки, не имеющие отношения к конкретному сценарию. При подавлении ошибки рекомендуется вести журнал рабочего элемента в Team Foundation. Сведения о выполнении этой задачи см. в разделе Проверка кода с помощью схем зависимостей.
Включить проверку слоев в процессе сборки
Чтобы обеспечить соответствие будущих изменений в коде схемам зависимостей, включите проверку слоев в стандартный процесс сборки решения. Каждый раз, когда другие члены команды создают решение, любые различия между зависимостями в коде и схемой зависимостей будут отображаться как ошибки сборки. Дополнительные сведения о включении проверки слоев в процесс сборки см. в разделе Проверка кода с помощью схем зависимостей.
Если в решении есть проекты, которые зависят друг от друга, т. е. один проект зависит от типов другого проекта и использует их, то Visual Studio должна знать порядок сборки проектов. Для примера рассмотрим проект приложения Windows, который использует типы, предоставляемые проектом библиотеки классов. Если в последовательности сборки сначала не будет собрана библиотека классов, то процесс сборки закончится неудачно.
В большинстве случаев Visual Studio способна сама определить правильную последовательность сборки. Однако иногда вам может понадобиться вручную указать, что некий проект зависит от других проектов. Для предоставления такой информации используйте страницу свойств Project Dependencies (рис. 4.7). Выберите проект в раскрывающемся списке, а затем укажите, от каких решений он зависит (для этого нужно отметить проекты в окне списка Depends on).
Местоположение файлов исходных кодов для отладки
В определенных ситуациях вам может понадобиться явно указать отладчику Visual Studio файлы исходных кодов для использования в процессе работы отладчика.
Одна из таких ситуаций — это когда вы пытаетесь отлаживать решение, которое ссылается на объект на удаленном компьютере. Если файл исходного кода для этого удаленного объекта на локальном компьютере отсутствует, то вы можете явно указать для Visual Studio файлы исходных кодов.
Для того чтобы добавить элемент в любое из полей, сначала поместите ваш курсор в поле, а затем щелкните кнопку New Line (вверху справа в диалоговом окне). Это позволит вам ввести полностью квалифицированный путь к нужному каталогу. Удаляется элемент путем его выделения и последующего щелчка по кнопке Cut Line. Кнопка Check Entries позволяет вам еще раз перепроверить, что все элементы указывают на правильные и доступные пути к каталогам.
Если вы загрузили решение с проектами на языке Visual C++, то, вероятно, сразу же увидите несколько элементов в списке Directories containing source code.
3 ответа
Я надеюсь, что у них есть лучший способ сообщить о проблемах со ссылками, чем немаркированный желтый значок.
Не уверен, что это ваш настоящий вопрос. Но вы можете проверить Окно списка ошибок , чтобы узнать, почему желтый значок отображается в списке ссылок.
Все строит и работает нормально.
Для некоторого сценария сборка в VS может быть успешной, хотя появляются некоторые предупреждения. И он потерпит неудачу, только если существуют ошибки сборки.
Я добавляю ссылку на ForTest.dll в моем проекте, эта сборка отсутствует или несовместима с текущим проектом, затем в References отображается желтый значок . Теперь, поскольку в моем проекте он не вызывает функции из ForTest.dll , поэтому он не повлияет на мой процесс сборки. Затем проект строится успешно и работает нормально.
Или просто используйте Окно списка ошибок , как я предлагаю выше, чтобы проверить предупреждения и ошибки вместо сотен журналов во время устранения неполадок.
Кроме того, если вы не можете найти какую-либо информацию в окне списка ошибок , возможно, причина появления желтого значка заключается в том, что > . Пожалуйста, попробуйте right-click the project=> unload and reload the project в solution explorer . Если это не устраняется, закройте все против экземпляра и удалите папку .vs в каталоге решений и перезапустите
Согласно Microsoft, эти желтые предупреждающие знаки добавляются для каждой новой ссылки, а затем удаляются после успешного добавления ссылки (= предполагается, что она виновна, пока не доказана невиновность). Если в обозревателе решений остается какое-то желтое предупреждение, VS знает только, что эта ссылка отсутствует, но не знает, почему, и поэтому не может отображать предупреждение в окне «Ошибка».
Невозможность выяснить, почему есть предупреждающий знак, очень раздражает. О проблеме сообщили, но стандартный ответ Microsoft таков: «Кажется, эта проблема не запрошена настолько, чтобы ее можно было решить, но, если хотите, вы можете предложить свое собственное решение».
Потратив часы, пытаясь решить несуществующую ошибку, я сдался и закрыл VS. Когда я начал это снова, проблема исчезла.
Убедитесь, что зависимость пакета совпадает с проектом, с которым вы работаете.
Читайте также: