Я поддерживаю свою собственную структуру, чтобы все мои вещи были в одном месте (помощники, локализация, ведение журнала, кэширование, отображение, аутентификация, ...).Во время разработки решения используют зависимости проекта, как показано ниже:
F: папка, P: проект, PD: зависимость проекта, ND: зависимость NuGet
Solution FrameworkX
|-- F: Template
| |-- P: FrameworkX.Template.Business
| | |-- PD: FrameworkX.Model
| |
| |-- P: FrameworkX.Template.Model
| | |-- PD: FrameworkX.Identity
| | |-- PD: FrameworkX.Model
|
| |-- P: FrameworkX.Template.WebUI
| | |-- PD: FrameworkX.Telerik
| | |-- PD: FrameworkX.Template.Business
| | |-- PD: FrameworkX.Template.Model
| | |-- PD: FrameworkX.Web
|
|-- P: FrameworkX.Common
|
|-- P: FrameworkX.Identity
| |-- PD: FrameworkX.Common
|
|-- P: FrameworkX.Model
| |-- PD: FrameworkX.Common
|
|-- P: FrameworkX.Telerik
| |-- PD: FrameworkX.Common
| |-- PD: FrameworkX.Model
|
|-- P: FrameworkX.Web
| |-- PD: FrameworkX.Common
| |-- PD: FrameworkX.Identity
| |-- PD: FrameworkX.Model
Процесс публикацииразделен на две части.Во-первых, каждый из не шаблонных проектов должен быть упакован в отдельный пакет NuGet с возможной зависимостью от других пакетов NuGet (ссылаясь на другие пакеты моей платформы).
Q1: Isэто хорошая идея для ссылки на другие пакеты NuGet моего собственного решения?Либо с зависимостями проекта и NuGet, это своего рода ад сборки, если один проект получает обновление.
Q2: В настоящий момент я вручную изменяю тип зависимости с проекта на NuGet при сборке и упаковке каждого из них.проектов, один за другим, чтобы поддерживать правильный порядок сборки / упаковки.Есть ли способ лучше?Ну, я мог бы написать весь процесс, но основы все те же.
Q3: Прямо сейчас, с одним небольшим изменением в пакете, подобном FrameworkX.Common, которое действительно влияет только на вспомогательный метод, используемый вFrameworkX.Model означает, что все остальные проекты должны быть перестроены и упакованы.Иначе, например, у проекта FrameworkX.Web однажды будет зависимость через FrameworkX.Model, которая новее, чем у FrameworkX.Identity.Есть ли выход из этого беспорядка?
Как это должно выглядеть потом:
Solution FrameworkX
|-- F: Template
| |-- P: FrameworkX.Template.Business
| | |-- ND: FrameworkX.Model
| |
| |-- P: FrameworkX.Template.Model
| | |-- ND: FrameworkX.Identity
| | |-- ND: FrameworkX.Model
|
| |-- P: FrameworkX.Template.WebUI
| | |-- ND: FrameworkX.Telerik
| | |-- PD: FrameworkX.Template.Business
| | |-- PD: FrameworkX.Template.Model
| | |-- ND: FrameworkX.Web
|
|-- P: FrameworkX.Common
|
|-- P: FrameworkX.Identity
| |-- ND: FrameworkX.Common
|
|-- P: FrameworkX.Model
| |-- ND: FrameworkX.Common
|
|-- P: FrameworkX.Telerik
| |-- ND: FrameworkX.Common
| |-- ND: FrameworkX.Model
|
|-- P: FrameworkX.Web
| |-- ND: FrameworkX.Common
| |-- ND: FrameworkX.Identity
| |-- ND: FrameworkX.Model
Q4: Независимо от вопроса выше (который может повлиять наэто вопросы) как бы вы справились с переходом с одного вида зависимости на другой?Сценарии?
К счастью, файлы проектов ядра .NET довольно легко изменить, поскольку они не включают в себя все необходимые файлы, как в полной .NET Framework.