Контент-файлы с NuGet очень-очень медленные

У меня есть обычное веб-приложение ASP.NET, которое используется несколькими сайтами. Я использовал NuGet, чтобы упаковать это обычное веб-приложение и распространить его по нескольким сайтам. Следуя этой идее: несколько веб-приложений ASP.NET в зависимости от общего базового приложения.

Делая это, я получаю некоторые проблемы. При обновлении до новой версии NuGet становится очень медленным. Это из-за 800 файлов контента, которые он содержит. Каким-то образом NuGet требуется около 1–2 секунд для удаления каждого файла содержимого, в результате чего на удаление уходит примерно 25 минут, а на установку – 5 минут. Особенно с TFS-привязкой. Глядя на исходный код NuGet, я понял, что API Visual Studio, с которым общается NuGet, является узким местом. Вынуждение Visual Studio на пике 100% загрузки ЦП на протяжении всего процесса.

Поэтому я подумал, что если Visual Studio такая медленная, возможно, я смогу обойтись без нее. К моему разочарованию, командная строка NuGet (которая работает без Visual Studio) только загружает пакет и распаковывает его. Он не будет обновлять файл проекта из-за того, что некоторые Powershell-скрипты могут ссылаться на DTE-объект... (хотя я этого не делаю).

Теперь мне интересно: какие у меня есть варианты?

  1. Выполняете некоторую XML-магию в файле проекта, чтобы добавить элементы контента? Каковы недостатки этого? Есть ли уже инструмент для этого?
  2. Совершаете магию со скриптами сборки?
  3. Выбросить файлы содержимого из пакета и использовать другой инструмент, например Bower или что-то в этом роде? Как это можно интегрировать в проект? Потому что в конечном итоге я хочу увидеть файлы контента, которые у меня есть.
  4. Не используя NuGet вообще, а что-то еще...? Открытая упаковка? Рог? (кажется, больше не активен) А может вообще нет менеджера пакетов?

Пожалуйста, помогите мне найти лучшее решение :)

.

Еще одна вещь, которая меня расстраивает, заключается в том, что при выполнении обновления NuGet выполняется удаление, за которым следует установка. Зачем, если изменения между версиями могут быть минимальными?


visual-studio c# asp.net nuget package-managers
person sebas2day    schedule 28.04.2014    source источник

Ответы (1)


arrow_upward
1
arrow_downward

Один из вариантов заключается в том, что вместо добавления 800 файлов содержимого вы можете встроить их в качестве ресурсов в свою общую библиотеку.

Затем используйте что-то вроде EmbeddedResourceVirtualPathProvider https://github.com/mcintyre321/EmbeddedResourceVirtualPathProvider для их обслуживания.

Таким образом, NuGet просто заменяет .dll вместо 800 отдельных файлов.

В Интернете есть множество статей о том, как использовать VirtualPathProvider.

EDIT: вопросы о производительности

Решение кажется относительно простым, поэтому я бы просто попробовал его и посмотрел, приемлема ли производительность. Приятно то, что вам не нужно делать ничего особенного с путями в вашем веб-приложении.

Вот шаги, которые вам нужно сделать:

  1. В библиотеке ресурсов задайте для файлов содержимого встроенный ресурс. Вы можете сделать это быстро, открыв файл .csproj в текстовом редакторе и заменив <Content на <EmbeddedResource.
  2. Добавьте ссылку на библиотеку ресурсов в свое веб-приложение.
  3. Добавьте пакет EmbeddedResourceVirtualPathProvider NuGet в свое веб-приложение.
  4. Зарегистрируйте провайдера виртуального пути. Вот пример регистрации с использованием AppInitialize(), хранящегося в папке App_Code.
namespace TestWebProject.App_Code
{
    public class RegisterVirtualPathProvider
    {
        public static void AppInitialize()
        {
            HostingEnvironment.RegisterVirtualPathProvider(new EmbeddedResourceVirtualPathProvider.Vpp()
            {
                {typeof (Marker).Assembly, @"..\TestResourceLibrary"},

            });
        }
    }
}
person Kiliman    schedule 28.04.2014
comment
Звучит как хорошее решение, есть ли недостатки при его использовании? Как возможная задержка производительности для конечных пользователей? - person sebas2day; 29.04.2014
comment
Обновленный ответ с дополнительной информацией - person Kiliman; 29.04.2014
comment
@sebas2day, есть проблемы с производительностью, он занимает больше памяти, так как вся сборка находится в памяти, и загрузка приложения будет медленнее, IIS не будет кэшировать их как статическое содержимое, IIS также не будет сжимать их как сжатие статического содержимого, вы в конечном итоге использовать больше процессора во время выполнения. - person Akash Kava; 31.03.2015