Как управлять ссылками в SVN / Visual Studio?

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

основные проблемы:

1 -) Должен ли я включать все проекты, которые я использую в том же решении, и ссылаться на проект? Или ссылаться только на dll-файл?

2-) Если я должен ссылаться на dll-файл, лучший способ-создать ReferencedAssemblies внутри каждого проекта или основную папку в корне svn?

3 -) его ОК вставить и ссылки DLL внутри bin папка моего проекта?

4 -) его ok добавить и зафиксировать DLL внутри папки bin моего проекта? Таким образом, когда новый devoloper проверяет проект, он будет компилироваться идеально, но это не поведение по умолчанию visual studio, все элементы управления версиями игнорируют bin и obj по умолчанию, просто добавляя .обновить файлы (для проекта веб-сайта)

кто может мне помочь?

7
svn version-control visual-studio

3 ответов

1) Если в решение включены проекты, которые уже зарегистрированы в другом месте, можно изменить привязку SVN для этого проекта на уровне решения в Visual Studio. (Файл > Источник Управления > Источник Изменений). Вы бы изменили его, чтобы указать, где он находится в вашем SVN repo.

2) Если у вас есть много разработчиков на разных машинах, желающих использовать одни и те же библиотеки, вероятно, проще иметь общее место для всех ваших сторонних разработчиков библиотеки/собрания. Нет смысла копировать их повсюду в хранилище SVN.

3) Нет, обычно это не нормально. Я бы избегал этого (если у кого-то нет веской причины для этого).

4) Никогда не фиксируйте папки bin. Поведение по умолчанию такое по какой-то причине. Этот.файлы обновления являются побочными продуктами старой сети сайт проекты, и они в порядке.

3

1) в типичном сценарии да, вы должны ссылаться на все проекты, которые у вас есть. Но вы должны принять решение в соответствии с частотой изменений, внесенных в ссылочные проекты. Например, если у вас есть библиотека с открытым исходным кодом, лучше включить ее в качестве сборки, потому что вы, вероятно, не будете часто менять этот код.

2) типичный подход заключается в создании отдельного отдельного каталога в корне SVN и размещении сборок там в разных подпапки в соответствии с типом сборок. Вот как выглядит моя текущая папка: alt text

3) нет, лучше ссылаться на сборки из некоторых других из bin. Все сборки будут скопированы в bin в процессе строительства. Также отметим, что цель *.обновить файлы в папке bin-это предотвратить копирование новых версий самостоятельно.

4) нет, вы никогда не должны совершать папку bin, потому что вы можете положиться на *.обновите файлы для веб-сайтов и просто забудьте об этой проблеме для других типов проектов.

2

1) я бы сказал, что это зависит от вашей конкретной ситуации, тем более, что Visual Studio довольно гибка в том, какие проекты включены в решения. (Он не привязан к структуре каталогов.)

У нас есть несколько приложений, которые имеют одно решение с несколькими проектами, содержащимися внутри (для каждой "части").

2, 3, 4) для ссылок и включения файлов в проект, почему бы просто не использовать функциональность, встроенную в Visual Studio? Добавление ссылок в таким образом, элементы добавляются в файлы csproj (vbproj).

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

<Reference Include="Elmah">
    <HintPath>\pathInformation\shared assemblies\ELMAH 1.1 32-bit\Elmah.dll</HintPath>
</Reference>

)

Это также означает, что вам не нужно фиксировать DLL; если что-то изменится, файл проекта будет обновлен соответствующим образом.

(Я признаюсь, я не уверен насчет последнего пункта. Я видел, как многие люди проверяют внешние библиотеки, такие как ELMAH. Я обычно следую за теми, кто говорит вам полностью игнорировать каталог bin.)

0