Ссылка на проект и ссылка на файл?
Ссылки могут быть добавлены в проекте двумя способами.
- Ссылка на проект.
- Ссылка на файл.
Но, когда использовать проект и когда использовать ссылку на файл?
11 ответов
Вы не указали, но я предполагаю, что вы имеете в виду Visual Studio?
Основное различие между ссылкой на проект и ссылкой на файл заключается в том, доступны ли прямые обновления. В справочнике по проекту вы сможете увидеть результаты редактирования одного проекта сразу в другом проекте с помощью таких элементов, как Intellisense. Так, например, если вы добавите класс с именем Foo, этот тип будет сразу же отображаться в intellisense в любом проекте, в котором есть ссылка на этот проект.
С другой стороны, ссылки на файлы могут видеть только те изменения, которые присутствуют на диске. Компиляция должна быть выполнена и биты записаны на диск, чтобы увидеть изменения.
В общем, лучше использовать ссылку на проект.
Другим аспектом, который необходимо учитывать, являются относительные языки проектов. Ссылки между проектами максимально полезны, если язык в обоих проектах одинаков. Если языки разные, они, как правило, рассматриваются как ссылки на файлы, а не на проекты.
Я только что прошел через это...
Мы получили от поставщика около 53 различных файлов решения VS2005 C#, которые создали 63 различных.dll проекта, каждый из которых вызывается отдельным коммерческим приложением.
Все проекты содержали ссылки на файлы в библиотеках других проектов.
Проблемы с этим подходом были велики: взаимозависимости практически невозможно было отработать, включая множество команд "findstr"; функциональность "найти определение" в VS не найдет источник для DLL-файлов, на которые ссылаются файлы, а только покажет определения функций внутри библиотек; восстановление из-за изменений было подвержено ошибкам, обременительно и требовало открытия множества различных решений для повторного построения всего набора DLL.
Я потратил недели на объединение 53 различных файлов решений в одно, а затем потратил дополнительное время на изменение всех файловых зависимостей на зависимости проекта. Теперь, когда вы "нашли определение", вы попадаете в исходный файл. Теперь, когда вы изменяете низкоуровневый проект, все зависимые проекты будут создаваться при создании (одного) решения.
Я сделал несколько дополнительных изменений, но самым удобным было установить все директории сборки отдельных проектов в Solution Dir/ bin. Таким образом, все библиотеки оказываются в одном месте.
О, да: я также установил "копировать локально" в "нет" для всех библиотек указанных проектов. Таким образом, каждая dll отображается в Solution Dir/ bin при сборке проекта и определяется следующими проектами для сборки.
Единственная проблема, с которой мы столкнулись сейчас, заключается в том, что если я изменю проект, который используется в качестве источника данных для другого проекта с формой Windows, тогда форма Windows не откроется в Designer, пока я не перестрою проект, который является источником данных для формы. Маленькая, маленькая цена, чтобы заплатить за все преимущества ссылок на проекты. Кроме того, я должен построить решение после извлечения из SVN, потому что DLL не находятся в SVN. В приведенном выше случае источник данных.dll не найден для Designer.
Используйте "ссылку на проект", чтобы добавить ссылку на сборки в вашем решении.
Используйте "ссылку на файл", чтобы добавить ссылку на сборки кросс-решения
Я столкнулся с проблемами в нескольких проектах, где ссылки на файлы просто не сокращают его. Устаревшие ссылки вызывают проблемы с буку. Microsoft рекомендует использовать ссылки на файлы только в случае необходимости:
Использует ссылки:
http://www.ssw.com.au/ssw/Standards/Rules/RulesToBetterLargedotNETProjects.aspx
http://blogs.msdn.com/b/ricom/archive/2004/10/18/244242.aspx
Я специально поручил нашей группе разработчиков использовать ссылки на файлы, а не ссылки на проекты в большинстве случаев: мы работаем в области с высокой степенью целостности. Таким образом, каждый компонент, который не является непосредственно частью этой работы (т. Е. Материал, который используется совместно с другими проектами), не должен быть изменен произвольно. Таким образом, идея заключается в том, чтобы (в идеальной работе, не связанной с новыми технологиями) мы взяли протестированные, авторизованные, известные версии подкомпонентов из области выпуска в сети и включили их в область компонентов решения.
Это предназначено для упрощения обслуживания и тестирования, поскольку следует избегать распространения многих похожих версий, все с разными номерами сборки или SVN.
Вторая причина (и, вероятно, мой опыт работы с C/C++) заключается в том, что я хотел бы знать, что я использую все Debug или все версии Release. Вы не можете сделать это легко в проектах.NET. Мы строим в каталог компонентов \$configuration$, а затем выполняем шаг после сборки, чтобы скопировать из компонентов \$configuration$ в каталог выше. Все ссылки на файлы относятся к файлам в каталоге компонентов только в том смысле (я полагаю), что у нас действительно есть сборки отладки и выпуска, сделанные по всей цепочке.
Если вы отправляете на внешние серверы, я считаю, вы должны учитывать, что выходящие библиотеки DLL должны быть одинаковыми для всех пользователей, в противном случае вы рискуете не иметь возможности легко отладить проблемы позже (отслеживание конфигурации от исходного кода до доставленных исполняемых файлов).
В конце все ссылки являются ссылками на файлы, ссылка на проект - это просто визуальная функция студии, которая делает ссылку на файл, который создается с вашим решением, поэтому, когда вы создаете новую сборку, ссылка обновляется автоматически без вы собираетесь скопировать и вставить файлы
Причина, по которой я обращаюсь к ссылке на файл (даже если у меня есть источник или сам создавал сборку), заключается в том, что эта конкретная сборка не сильно меняется (скажем, раз в полгода). Просто чтобы побрить время сборки. Кроме того, некоторые проекты автоматически увеличивают свой номер версии (например, попробуйте включить проект AjaxControlToolkit в свое решение).
Одна ошибка (C1083), которая была у меня при переключении на ссылки (и удаление относительных включений), была "Заголовок не найден". Я имел:
- в настройках включить каталог:
../../src/module - в исходном коде:
#include "file.h"
Исправьте относительный путь, чтобы он работал:
#include "module/file.h"
Когда проект перестраивается, все проекты, которые ссылаются на него, также автоматически перестраиваются.
Это не верно для ссылок на файлы.
На самом деле оба метода используют ссылки на файлы. Ссылка на проект полезна для VS, чтобы знать, когда должен быть создан ссылочный Проект VS
s