2013-02-18 2 views
0

Извините, здесь есть несколько вопросов noobish ... час работы в Google и в справочных документах MS, моя голова оказалась не в том месте, я не могу понять это.Включить ссылку в структуру файла проекта

У меня есть проект C#, созданный в Visual Studio 2012, который имеет ссылки на несколько DLL-файлов, которые у меня есть на моем собственном жестком диске (NetOffice .dlls, для конкретных, для Excel Interop). Я добавляю их, щелкнув правой кнопкой мыши по папке с моими ссылками, перейдя в ссылку «Добавить ссылку», а затем «Обзор», чтобы найти файлы. В этот момент они включены, и на моей стороне все работает так, как ожидалось.

Проблема возникает, когда я делюсь проектом. Я использую Git для координации проекта между собой и несколькими членами команды. Я запустил свою фиксацию и подтолкнул ее, чтобы мой товарищ по команде сделал все возможное. Все отображается на его компьютере правильно, но когда мы открываем проект, он сообщает мне, что NetOffice .dll отсутствуют.

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

У нас есть несколько пакетов NuGet, которые мы используем, и они, похоже, работают отлично после передачи. Я также перешел в свойства .dll для NetOffice и превратил «Копировать локальную» в true, но он все еще не включен.

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

+0

Почему этот вопрос был опущен? Люди, если вы занимаетесь ниспровержением, по крайней мере, любезно объясните нисходящее движение! – Christian

+0

Потому что, @Christian, ясно последние четыре часа времени я провел исследование ответа до публикации не посчитал? Лорд простите меня за то, что я был новым, я думаю ... (извините, немного непрофессионально, но это больше, чем просто разочарование, чтобы задать честный вопрос, как можно лучше, а затем получить downvoted.) –

+0

Если у вас есть непубличные зависимостей, которые сильно меняются, возможно, стоит подумать о создании локального репозитория NuGet. Таким образом, разработчики могут получить необходимые зависимости с помощью NuGet, а созданные двоичные файлы из зависимостей не должны быть добавлены в исходный элемент управления. Если зависимости довольно стабильны, добавление их в исходный элемент управления обычно не является проблемой. – poke

ответ

2

1 Создайте папку в файловой системе на том же уровне, что и файл решения.
2 Скопируйте внешние dll в эту папку.
3 Добавить решение Папка решения.
-Добавить каждый DLL в папку решения с помощью добавления существующего элемента
5 Ссылки библиотек в решении

шаги 3 и 4 не является действительно необходимы, но они помогают держать вещи организовано.

+0

Спасибо! По какой-то причине я уволил эту идею на ранней стадии. Я думаю, что у меня недавно был опыт, когда это не помогло, потому что путь к файлу не был относительным. Это фиксировало это. –

1

Хотя не рекомендуется включать двоичные файлы в ваш репозиторий git, это позволит решить вашу проблему.

Быстрое исправление может заключаться в создании каталогов lib в разумных местах в вашем репозитории (я не разработчик C#, но предложение Гамы Феликса кажется правильным).

Затем зафиксируйте эти папки и нажмите на сервер.

+0

Да, я собираюсь сделать то, что сказал Гама, но мне интересно, что бы вы сказали, лучшая практика? –

+0

Намного лучше использовать диспетчер пакетов. Мой опыт в основном связан с Java ([Maven] (http://maven.apache.org/)) и Ruby ([Bundler] (http://gembundler.com/)), поэтому я не могу дать вам твердого предложения для C# - хотя я думаю, что NuGet может работать аналогичным образом. По сути, вы хотите отделить свой код от его зависимостей. –

+0

Вы должны назвать эту папку 'lib' или что-то еще, поскольку в каталоге' bin' содержатся файлы, сгенерированные Visual Studio при компиляции. – poke

1

Давайте предположим, что ваш исходный контроль корневой каталог называется SourceRoot
и ваши файлы решения находятся под папку под названием JaySolutionFolder
Я предпочитаю:
Добавление новой папки для управления версиями, под SourceRoot, называется SharedDlls
Скопируйте все внешние Dlls в эту папку.
Добавьте эту ссылку dll SharedDlls в свой проект.
Зафиксировать эту папку
Теперь ваши товарищи по команде должны получить JaySolutionFolder & SharedDlls для компиляции источников.
Позже это SharedDlls может быть целевым каталогом процесса сборки (с использованием таких инструментов, как TFS Bulid, NANT или еще)
Это будет способ минимизировать проблемы разработки на основе команды.
В версии и установки программного обеспечения, вы можете использовать монтажников или пакет программного обеспечения строителей как installshield или Visual Studio Setup Package или ... для решения внешних проблем
DLLs хоп это помогает.

Смежные вопросы