Подтвердить что ты не робот

ASP.NET 5 (vNext) различные зависимости для сборки Release и Debug

У нас есть проект ASP.NET MVC 5, который мы разрабатываем, который зависит от проектов из другого решения. Другое решение - это библиотеки классов, которые являются общими, и мы публикуем их как пакеты NuGet. Когда мы выпускаем, мы собираем проект и берем его из репозитория NuGet, но пока мы находимся в разработке, мы берем ссылку из папки bin этого проекта.

Чтобы получить эту работу, мы выполнили "взломать" файл csproj из проекта ASP.NET(мы вручную отредактировали файл csproj xml и изменили ссылку):

<Reference Include="Common.Utilities, Culture=neutral, processorArchitecture=MSIL">
    <SpecificVersion>False</SpecificVersion>
    <HintPath Condition=" '$(Configuration)' == 'Debug' ">..\..\..\Common\Common.Utilities\bin\$(Configuration)\Common.Utilities.dll</HintPath>
    <HintPath Condition=" '$(Configuration)' != 'Debug' ">..\..\..\..\ExtrnBin\NuGetPackages\Common.Utilities.1.0.0.8\lib\net451\Common.Utilities.dll</HintPath>
</Reference>

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

Теперь мы тестируем ASP.NET 5, а зависимости больше не определены в файле csproj, а в файле project.json. Поэтому, если мы добавим ссылку, мы получим что-то вроде этого в project.json:

"dependencies": {
    "EntityFramework.Commands": "7.0.0-rc1-final",
    "EntityFramework.MicrosoftSqlServer": "7.0.0-rc1-final",
    "Microsoft.ApplicationInsights.AspNet": "1.0.0-rc1",
    "Microsoft.AspNet.Authentication.Cookies": "1.0.0-rc1-final",
    "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc1-final",
    "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-rc1-final",
    "Microsoft.AspNet.IISPlatformHandler": "1.0.0-rc1-final",
    "Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
    "Microsoft.AspNet.Mvc.TagHelpers": "6.0.0-rc1-final",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
    "Microsoft.AspNet.Tooling.Razor": "1.0.0-rc1-final",
    "Microsoft.Extensions.CodeGenerators.Mvc": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.FileProviderExtensions": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
    "Microsoft.Extensions.Configuration.UserSecrets": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final",
    "Microsoft.Extensions.Logging.Debug": "1.0.0-rc1-final",
    "Microsoft.VisualStudio.Web.BrowserLink.Loader": "14.0.0-rc1-final",
    "Common.Utilities": "1.0.0.8-*"
}

он также создает папку-оболочку и копирует DLL в папку lib\dnx\451.

Как мы можем настроить что-то похожее на то, что у нас было раньше, чтобы поддерживать 2 конфигурации сборки?

4b9b3361

ОТВЕТЫ

Ответ 1

Короткий ответ

Вы не можете избежать повторной публикации; но вы можете избежать повторной публикации удаленно.

В каждой сборке вашего решения библиотеки классов опубликуйте пакет NuGet в локальный каталог, например C:\LocalPackages. В вашем проекте MVC используйте два разных источника пакета NuGet: один для выпуска, другой для отладки. Создайте источник отладки C:\LocalPackages.

Отладка будет взята из локального источника NuGet, релиз будет получен из загруженного NuGet.

Пример из репозитория ядра ASP.NET

репозиторий ASP.NET MVC использует разные packageSources для разных сборок. Один ответ на ваш вопрос заключается в том, чтобы использовать тот же подход, но с локальными packageSources для сборки разработки.

aspnet release branch > nuget.config

<packageSources>
  <clear />
  <add key="AspNetVNext" value="https://www.myget.org/f/aspnetmaster/api/v3/index.json" />
  <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>

aspnet dev branch > nuget.config

<packageSources>
  <add key="AspNetVNext" value="https://www.myget.org/F/aspnetcidev/api/v3/index.json" />
  <add key="NuGet" value="https://api.nuget.org/v3/index.json" />
</packageSources>

Рабочий процесс для быстрого быстрого развития

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

Производить пакеты NuGet при сборке

В Visual Studio 2015 создайте новый Class Library (Package). Настройте его для публикации пакетов в локальном каталоге при сборке. Другими словами...

  • Щелкните правой кнопкой мыши проект.
  • Выберите "Свойства".
  • На вкладке "Сборка" выберите "Произвести выходы при сборке".

Каждая сборка теперь выводит библиотеку классов в виде пакета NuGet в каталог решения artifacts.

Автоматически публиковать пакеты NuGet в локальном каталоге при сборке

Чтобы получить доступ ко всем нашим пакетам в одном локальном источнике NuGet, добавьте следующую postpack script в библиотеку классов project.json. script копирует пакет в наш локальный исходный каталог NuGet. Опция /y перезаписывает существующие файлы.

project.json

"scripts": {
  "postpack": 
    "xcopy /y ..\\..\\artifacts\\bin\\%project:Name%\\Debug\\*.nupkg C:\\LocalPackages\\"
}

См. примечания для альтернативного script, который копирует пакеты отладки и/или выпуска.

Настройте проект MVC для использования локального каталога NuGet

Откройте проект MVC, который находится в отдельном решении. См. Примечания относительно способа определения пакетов решений без изменения глобальных настроек NuGet.

  • Выберите "Инструменты" > "Диспетчер пакетов NuGet" > "Параметры диспетчера пакетов"
  • Выберите источники пакетов.
  • Добавьте новый источник пакета с именем LocalPackages.
  • Установите источник C:\LocalPackages.
  • Нажмите "Обновить".

Когда вы готовы опубликовать, замените запись LocalPackages на соответствующий источник NuGet для производства.

Указание на локальные пакеты

Добавить локальные пакеты NuGet в ваш проект

Из проекта MVC обращайтесь к локальным пакетам NuGet.

  • Выберите "Инструменты" > "Диспетчер пакетов NuGet" > "Управление пакетами NuGet для решения"
  • Задайте источник пакета LocalPackages.
  • Выберите вкладку просмотра.
  • Установите локальные пакеты.

Использование локальных пакетов

Примечания

(1) Для использования пакетов Debug и Release в нашем проекте используйте postpack script.

for /r "..\\" %i in (*.nupkg) do xcopy /y %i C:\LocalPackages`

(2) Visual Studio добавляет источники пакета NuGet в файл ~\AppData\Roaming\NuGet\nuget.config. В качестве альтернативы, создайте nuget.config в корне нашего решения.

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="LocalPackages" value="C:\LocalPackages" />
  </packageSources>
</configuration>