Хорошая стратегия для разделения проектных зависимостей / ресурсов между несколькими проектами / блоками / разработчиками? - PullRequest
0 голосов
/ 21 сентября 2010

Я работаю в небольшой команде разработчиков с 3-мя разработчиками, и никто из нас не является «программистом высшей элиты», но мы неплохо справляемся с нашей компанией. Одна вещь, которая постоянно повторяется, это то, что мы продолжаем использовать одни и те же ресурсы в нескольких проектах. Одним из примеров является элемент управления fckeditor, однако воняет постоянно добавлять эту папку в каждый проект (у меня есть набор элементов управления в моей панели инструментов, но он не сможет найти код, если у вас там нет папки ). Это также относится к постоянно повторяющимся главным страницам и элементам управления.

Теперь мы сделали несколько шагов для улучшения этого, в том числе сделали «бэкэнд-проект», в котором мы разместили наши общие функции, и создали CDN для изображений и сценариев. Но я все еще сталкиваюсь с проблемами. Например, все разработчики должны удостовериться, что у них установлена ​​и собрана последняя версия внутреннего проекта. Также, когда вы добавляете ссылку на этот .dll, пути должны быть одинаковыми между разработчиками, в противном случае это нарушает ссылку.

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

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

Редактировать: Использование VisualSVN 2.0 и Visual Studio 2010

Ответы [ 2 ]

1 голос
/ 21 сентября 2010

AFAIK, пользовательские элементы управления не могут быть разделены между проектами, так как они содержат HTML / ASPX, который привязан к определенному веб-приложению. Для этого существуют пользовательские элементы управления, поскольку они могут быть скомпилированы в MSIL и использованы в любых других проектах .NET.

Та же проблема с мастер-страницами, однако с мастер-страницами, если вы видите, что у вас есть «общая логика», используемая во всех веб-приложениях, почему бы не создать пользовательский элемент управления BaseMasterPage (расширяющий от MasterPage - без разметки) и вставить его в свой пользовательский управлять библиотекой, как указано выше? Следует помнить, что MSIL можно использовать повторно, а HTML / ASPX - нет.

Элементы управления веб-приложения не предназначены для совместного использования между различными веб-приложениями.

Попробуйте использовать общие функции, простые элементы управления в библиотеках классов и делитесь ими со своими разработчиками. Также используйте значимое пространство имен (CompanyName.Common.Controls), это должно помочь избежать этих конфликтов пути.

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

Почему бы не установить небольшую иконку в трее Windows, которая уведомляет, когда была произведена регистрация в этом общем проекте? Затем разработчики могут получить сборку.

Мы делаем это для уведомлений о сборке (проверки, успешная / неудачная сборка и т. Д.).

0 голосов
/ 21 сентября 2010

Предостережение: с точки зрения незнакомого с asp.net и пользовательского / пользовательского элементов управления, так как я занимаюсь разработкой winforms с помощью встроенных элементов управления .Net ... Кроме того, от пользователя Tv и TX, а не Visual SVN ... Следующее работает для файлов кода; Я не уверен, как работают пользовательские элементы управления.

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

Затем для каждого нового проекта я добавляю внешнюю зависимость SVN для каждого библиотечного проекта, который я хочу вызвать. Использование свойства svn: externals, примененного к каталогу внешних линий внешнего проекта, приведет к извлечению / обновлению библиотечного проекта в его собственную подпапку при каждом обновлении внешнего проекта. Изменения, внесенные в библиотеку, также могут быть зафиксированы при фиксации проекта.

Каждая строка в свойстве позволяет вам загрузить один библиотечный проект. Линии выглядят так:

Я использую tortis SVN для редактирования свойств (подробности в справке по пыткам); Анк SVN интерпретирует тогда правильно. Нет опыта работы с Visual SVN, вы можете редактировать свойства из Visual SVN или использовать командную строку SVN.

...