Ссылка на проект и ссылка на файл?

Question

Ссылки могут быть добавлены в проекте двумя способами.

1. Ссылка на проект.
2. Ссылка на файл.

Но, когда использовать Project и когда использовать ссылку на файл?

Answer 1

Вы не указали, но я предполагаю, что вы имеете в виду Visual Studio?

Основное различие между ссылкой на проект и ссылкой на файл заключается в том, доступны ли прямые обновления. В справочнике по проекту вы сможете сразу увидеть результаты редактирования одного проекта в другом проекте с помощью таких элементов, как Intellisense. Так, например, если вы добавите класс с именем Foo, этот тип будет сразу же отображаться в intellisense в любом проекте, в котором есть ссылка на этот проект.

С другой стороны, ссылки на файлы могут видеть только те изменения, которые присутствуют на диске. Компиляция должна быть выполнена и биты записаны на диск, чтобы увидеть изменения.

В общем, лучше использовать ссылку на проект.

Другим аспектом, который необходимо учитывать, являются относительные языки проектов. Ссылки между проектами максимально полезны, если язык в обоих проектах одинаков. Если языки разные, они, как правило, рассматриваются как ссылки на файлы, а не на проекты.

Answer 2

Я только что прошел это ...

Мы получили от поставщика около 53 различных файлов решения VS2005 C #, которые создали 63 различных DLL-файла проекта, каждый из которых вызывается отдельным коммерческим приложением.

Все проекты содержали ссылки на файлы в библиотеках других проектов.

Проблемы с этим подходом были велики: почти невозможно было создать зависимости между решениями, включая lot команд "findstr"; функциональность «найти определение» в VS не найдет источник для DLL-файлов, на которые ссылаются файлы, а только покажет определения функций внутри библиотек; восстановление из-за изменений было подвержено ошибкам, обременительно и требовало открытия множества различных решений для повторного построения всего набора DLL.

Я потратил недели на объединение 53 различных файлов решений в один, а затем потратил дополнительное время на изменение всех файловых зависимостей на зависимости проекта. Теперь, когда вы «нашли определение», вы попадаете в исходный файл. Теперь, когда вы изменяете проект низкого уровня, все зависимые проекты будут создаваться при создании (одного) решения.

Я сделал несколько дополнительных изменений, но самым удобным было установить для всех каталогов сборок отдельных проектов значение solutiondir / bin. Таким образом, все библиотеки оказываются в одном месте.

О да: я также установил «копировать локальный» в «нет» для всех dll всех упомянутых проектов. Таким образом, каждая dll отображается в solutiondir / bin при сборке проекта и обнаруживается в следующих проектах для сборки.

Единственная проблема, с которой мы столкнулись сейчас, заключается в том, что если я изменю проект, который используется в качестве источника данных для другого проекта с помощью формы Windows, то форма Windows не откроется в Designer, пока я не перестрою проект, который является источником данных для форма. Маленькая, маленькая цена, чтобы заплатить за все преимущества ссылок на проекты. Кроме того, я должен построить решение после извлечения из SVN, потому что DLL не находятся в SVN. В приведенном выше случае источник данных .dll не найден для Designer.

Answer 3

Используйте «ссылку на проект», чтобы добавить ссылку на сборки в вашем решении.

Используйте «ссылку на файл», чтобы добавить ссылку на перекрестные сборки решения

Источник

Answer 4

Я столкнулся с проблемами в нескольких проектах, где ссылки на файлы просто не сокращаются. Устаревшие ссылки вызывают проблемы с буку. Microsoft рекомендует использовать ссылки на файлы только в случае необходимости:

http://msdn.microsoft.com/en-us/library/ee817675.aspx

Answer 5

использует ссылки:

http://www.lostechies.com/blogs/chad_myers/archive/2008/07/15/project-anti-pattern-many-projects-in-a-visual-studio-solution-file.aspx

http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterLargedotNETProjects.aspx

http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx

Answer 6

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

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

Вторая причина (и, вероятно, мой опыт работы с C / C ++) заключается в том, что мне нравится знать, что я использую все версии Debug или все версии Release. Вы не можете сделать это легко в проектах .NET. Мы строим в каталог компонентов \ $ configuration $, а затем выполняем шаг после сборки, чтобы скопировать из компонентов \ $ configuration $ в каталог выше. Все ссылки на файлы относятся к файлам в каталоге компонентов только в том смысле (я считаю), что у нас действительно есть сборки отладки и выпуска, сделанные по всей цепочке.

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

Answer 7

Одна ошибка (C1083), которая возникла при переключении на ссылки (и удаление относительных включений), была «Заголовок не найден» У меня было:

• в настройках есть каталог: ../../src/module
• в исходном коде: #include "file.h"

---

Исправьте относительный путь, чтобы он работал:

#include "module/file.h"

Answer 8

На самом деле оба метода используют ссылки на файлы. Ссылка на проект полезна для VS, чтобы знать, когда ссылочный проект VS должен быть собран

S

Answer 9

Когда проект перестраивается, все проекты, на которые он ссылается, автоматически перестраиваются.

Это не относится к ссылкам на файлы.

Answer 10

Причина, по которой я обращаюсь к ссылке на файл (даже если у меня есть источник или сам создавал сборку), заключается в том, что эта конкретная сборка не сильно меняется (скажем, раз в полгода). Просто чтобы побрить время сборки. Кроме того, некоторые проекты автоматически увеличивают номер своей версии (например, попробуйте включить проект AjaxControlToolkit в свое решение).