Различные зависимости 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.

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


.net asp.net asp.net5
person developer82    schedule 29.03.2016    source источник
comment
Изменены теги, так как обсуждение шло о RC1. RC2 уже вышел, dot.net   -  person Lex Li    schedule 22.05.2016

Ответы (1)


arrow_upward
1
arrow_downward

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

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

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

Отладка возьмется из локального источника NuGet, релиз — из скачанного NuGet.

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

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

ветка aspnet release > 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 > 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). Настройте его для публикации пакетов в локальном каталоге при сборке. Другими словами...

  1. Щелкните проект правой кнопкой мыши.
  2. Выберите Свойства.
  3. На вкладке «Сборка» выберите «Производить выходные данные при сборке».

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

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

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

проект.json

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

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

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

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

  1. Выберите «Инструменты» > «Диспетчер пакетов NuGet» > «Настройки диспетчера пакетов».
  2. Щелкните Источники пакетов.
  3. Добавьте новый источник пакета с именем LocalPackages.
  4. Установите его источник на C:\LocalPackages.
  5. Щелкните Обновить.

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

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

Добавьте локальные пакеты NuGet в свой проект.

Из проекта MVC получите доступ к локальным пакетам NuGet.

  1. Выберите «Инструменты» > «Диспетчер пакетов NuGet» > «Управление пакетами NuGet для решения».
  2. Установите источник пакета LocalPackages.
  3. Выберите вкладку обзора.
  4. Установите локальные пакеты.

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

Примечания

(1) Чтобы использовать в нашем проекте пакеты Debug и Release, используйте следующий скрипт postpack.

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>
person Shaun Luttin    schedule 29.03.2016
comment
OP заявляет, что их старое решение было очень полезным для быстрой разработки, поскольку нам не нужно повторно публиковать новый NuGet для каждого изменения. Этот ответ по-прежнему потребует развертывания NuGet для каждого изменения. - person Will Ray; 30.03.2016
comment
@Will Я думаю, что в наши дни мало что можно упаковать для NuGet, потому что .NET теперь ориентирован на разработку на основе пакетов. - person Shaun Luttin; 30.03.2016
comment
@ShaunLuttin, если я не ошибаюсь, ваше решение заставляет нас иметь другую ветку для разработки / выпуска и / или изменять расположение пакета в VS при изменении конфигурации сборки. Есть ли способ установить все заранее и позволить VS выбрать значение в соответствии с конфигурацией сборки? Кроме того, есть ли способ добиться этого без преобразования всех проектов в VS2015 (для поддержки пакетов проектов?) - person developer82; 07.04.2016