Как обращаться с разными csproj

Question

Я работаю в команде из пяти человек. Мы работаем над приложением C # с пятью csprojects.

Проблема в том, что для каждого csproject у каждого из моих коллег есть свои идеи о том, как ссылаться на DLL; некоторые хотели бы связать по ссылке проекта, другие хотели бы связать только в DLL. Таким образом, у каждого из нас будет свой проект.

Я хочу, чтобы все они проверили свой csproject; но, учитывая, что каждая копия csproject отличается, на самом деле не существует реально выполнимого механизма для этого, не так ли? Но если я не прошу их зарегистрировать свой csproject, то каждый раз, когда они добавляют новый файл, мне придется вручную редактировать мой csproject, и это очень утомительно, не говоря уже о том, что он превосходит цель непрерывной интеграции.

Есть ли стратегия, чтобы справиться с этим? Я знаю, что было бы лучше применить стандарт, но есть ли другой вариант, оставив это в стороне?

Есть причина, по которой содержание csproject отличается для всех; не у всех есть все пять csprojects, и не у всех может есть все 5 csprojects. Таким образом, неизменно некоторым придется в конечном итоге ссылаться на библиотеки DLL вместо проектов, а некоторые хотят ссылаться на проекты для простоты отладки. Если бы мне пришлось применять стандарт, как показывают ответы, я бы решил эту проблему.

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

Answer 1

Ваша проблема не в том, как справиться с этим с помощью Source Control.

Ваша проблема в том, что вам (или руководству) нужно, чтобы ваша команда приняла набор стандартов, которым следует вся команда.

Если вы позволите всем следовать своим собственным идеям и не получите командного сплочения по основам, это закончится слезами ...

Answer 2

Вы почти наверняка решаете не ту проблему. Если вы разветвляете файлы .csproj для удовлетворения отдельных предпочтений, вы выполняете дополнительную работу и вносите вероятность ошибок именно по той причине, которую вы описываете - каждый раз, когда Алиса добавляет файл в AlicesX.csproj, Боб должен узнать об этом. и добавьте тот же файл в BobsX.csproj.

Вы действительно должны рассматривать это как проблему стандартов и динамики команды: договориться о том, как библиотеки DLL будут ссылаться в основных источниках, и требовать, чтобы все придерживались этого. Если «проигравшей» стороне не нравится работать таким образом, они могут использовать свой предпочтительный стиль в своих личных рабочих копиях. Но на самом деле вам нужен только один главный источник, и вы хотите работать над тем, чтобы заставить всех купить способ, которым это делает главный источник.

В соответствии с вашими правками: Если вы действительно, действительно не можете прийти к соглашению с вашими коллегами, тогда я бы все же предложил одного мастера, но написал бы небольшую утилиту, которую могут использовать инакомыслящие, которая преобразует ссылки на проекты. к ссылкам на DLL (или наоборот). Файлы .csproj - это просто XML, так что это довольно тривиально. Если вы даже не можете договориться о формате репозитория, вам нужно будет поддерживать параллельные файлы .csproj, но я все равно напишу утилиту, чтобы гарантировать, что изменения, внесенные в DllReferencingProj.csproj, будут скопированы в ProjectReferencingProj.csproj. Но я все еще говорю, что вы просто делаете больше работы и накапливаете больше боли для себя, чем если бы у вас была ссора и с ней покончено: чтобы действовать как команда, вам нужно будет найти какой-то способ решения споры, и это так же хорошо, как любой тестовый пример.

Answer 3

Время заставить всех повзрослеть и следовать стандарту. Если вы все работаете над одним и тем же кодом, вы должны вместе решить, будет ли лучше ссылаться на dll или проект, а затем придерживаться его. Как только вы это поймете, вы можете решить, делать отступ в 2 или 4 пробела или табуляцию. Затем решите, следует ли помещать фигурные скобки в ту же строку или следующую строку после объявлений вашей функции. Я даже не собираюсь говорить с капризами венгерской нотации ...

Answer 4

Наша конфигурация следующая:

• Проект -> скопировать dll в общую папку
• Проект -> скопировать dll в общую папку
• Основной проект -> Скопировать exe в общую папку, запустить приложение из общей папки

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

Answer 5

Непрерывная интеграция не должна заботиться о ваших файлах .csproj. Я полагаю, это файлы MSBUILD? Или что-то?

Не используйте их для КИ. Они мусор. Они накапливают мусор, потому что делают слишком много вещей невидимыми. Создайте чистую структуру сборки, которая не зависит от них, вы будете благодарны, что сделали. И тогда проверяйте только файл проекта, когда вы добавляете что-то, и все остальные могут обновлять / объединять. Вам не нужно иметь одинаковые или даже похожие файлы проекта в большинстве случаев. В моей команде мы даже не запускаем одну и ту же версию VS на всех рабочих станциях.