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

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

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

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

Ответ 1

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

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

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

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

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

Ответ 2

Я просто прошел через это...

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

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

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

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

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

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

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

Ответ 3

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

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

Источник

Ответ 4

ссылки:

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

Ответ 5

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

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

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

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

Ответ 6

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

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

Ответ 7

В конце все ссылки являются ссылками на файлы, Project Reference - это просто визуальная студийная функция, которая ссылается на файл, который строится на вашем решении, поэтому всякий раз, когда вы строите новую сборку, ссылка автоматически обновляется без копирования и вставки файлов

Ответ 8

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

Ответ 9

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

Это неверно для ссылок на файлы.

Ответ 10

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

Ответ 11

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

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

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

#include "module/file.h"