Visual Studio Debug vs Release builds: локальные ресурсы и ресурсы nuget - PullRequest
0 голосов
/ 09 июля 2020

Недавно я создал несколько репозиториев publi c на github для различных C# библиотек и проектов, которые я разработал. Сегодня я столкнулся с проблемой, связанной с тем, как такие проекты потребляют другие библиотеки, которые я написал. Я предложил предварительное решение, но был бы признателен за отзывы о лучших практиках, других подходах и т. Д. c.

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

C:\Programming
+ -> GPLibrary
     + -> GPLibrary
          + -> GPLibrary.csproj
          + -> ...other files
+ -> ConsumingApp
     + -> ConsumingApp
          +-> ConsumingApp.csproj
          + -> ...other files

В решении ConsumingApp я создаю папку решения с именем 'externals', которая содержит ссылку на GPLibrary.

Я делаю это, потому что часто нахожу, что мне нужно настроить GPLibrary, чтобы расширить его функциональность, и я не хочу изменять go из-за проблем с публикацией большого количества мелких обновлений для nuget или локального репозитория. Я использую систему управления исходным кодом, чтобы поместить GPLibrary в ветку разработки, чтобы накопить эти незначительные изменения, и, когда их достаточно, я объединяю ветвь разработки обратно в основную ветку и создаю / publi sh обновленные пакеты nuget.

Это прекрасно работает ... при условии, что вы настроили свои решения и проекты так, как я. Если вы этого не сделали, и вы клонируете один из моих репозиториев publi c, вы не сможете его построить, пока вы не продублируете мою структуру диска и подход с папкой решения. Это неудобно для других разработчиков.

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

<Choose>
    <When Condition=" '$(Configuration)'=='Debug' ">
        <ItemGroup Condition=" '$(Configuration)' == 'Debug' ">
            <ProjectReference Include="..\..\EFCoreUtilities\EFCoreUtilities\EFCoreUtilities.csproj" />
            <ProjectReference Include="..\..\J4JLogging\AutoFacJ4JLogging\AutofacJ4JLogging.csproj" />
            <ProjectReference Include="..\..\J4JLogging\ConsoleChannel\ConsoleChannel.csproj" />
            <ProjectReference Include="..\..\J4JLogging\FileChannel\FileChannel.csproj" />
            <ProjectReference Include="..\..\J4JLogging\J4JLogging\J4JLogging.csproj" />
        </ItemGroup>
    </When>
    <When Condition=" '$(Configuration)'=='Release'">
        <ItemGroup>
            <PackageReference Include="J4JSoftware.EFCore.Utilities" Version="0.5.0" />
            <PackageReference Include="J4JSoftware.Logging" Version="2.5.1" />
            <PackageReference Include="J4JSoftware.Logging.Console" Version="2.5.1" />
            <PackageReference Include="J4JSoftware.Logging.File" Version="2.5.1" />
            <PackageReference Include="J4JSoftware.Logging.Autofac" Version="2.5.1" />
        </ItemGroup>
    </When>
</Choose>

Другим разработчикам все равно потребуется продублировать мой подход к созданию отладочных версий ConsumingApp, но они должны иметь возможность создавать версии Release без проблем.

Есть ли там лучший / более простой способ сделать это? Должен ли я, возможно, создать свою собственную конфигурацию специального назначения («DebugJ4J»), чтобы как «нормальная» конфигурация отладки, так и конфигурация выпуска могли использовать преимущества nuget, но я все еще мог использовать свой подход локально?

Кстати, я пробовал просто наличие нескольких секций ItemGroup, каждая из которых содержит условие Condition, но это, похоже, не работает. Не знаю почему. Но подход «Выбрать» подходит.

1 Ответ

1 голос
/ 09 июля 2020

Есть ли лучший / более простой способ сделать это? Должен ли я, возможно, создать свою собственную конфигурацию специального назначения («DebugJ4J»), чтобы и «нормальная» конфигурация отладки, и конфигурации выпуска могли использовать преимущества nuget, но я все еще мог использовать свой подход локально?

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

Итак, , когда другие члены сообщества используйте ваш образец, они также могут использовать Debug или Release Configuration без

Для создания новой конфигурации с именем DebugJ4J

Сборка -> Диспетчер конфигураций -> Конфигурация нового проекта ->

image // добавьте сюда любую ссылку на локальный проект. ............................ ...................... ....... ......... // Конфигурация отладки

В этой функции вы можете использовать эти пакеты nuget в обоих Debug и Release Configuration, а затем добавьте свои новые функции в DebugJ4J Configuration.

Примечание , что вы должны добавить условие в группу элементов, а затем включить все xml узлов в этой группе элементов. Как это:

<ItemGroup Condition="xxxxx">

..................

// all files under this condition

</ItemGroup>

...