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

Question

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

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

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

Answer 1

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

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

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

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

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

Answer 2

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

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

Source

Answer 3

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

Answer 4

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

Answer 5

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

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

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

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

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

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

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

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

Answer 6

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

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

Answer 7

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

сек

Answer 8

Utils ссылки:

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 9

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

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

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

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

Answer 10

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

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

Answer 11

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

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

---

Фикс относительный путь для его работы:

#include "module/file.h"