Question

我有一个由多个站点共享的通用ASP.NET Web应用程序。我使用NuGet打包这个常见的Web应用程序并将其分发到多个站点。遵循这个想法：Multiple ASP.NET web applications depending on a common base application。

通过这样做，我最终遇到了一些问题。更新新版本时，NuGet变得非常慢。这是因为它包含800个内容文件。不知何故，NuGet每个内容文件需要大约1~2秒才能卸载，最后大约 25分钟用于卸载，5分钟用于安装。特别是TFS绑定。看一下NuGet的源代码，我发现NuGet正在谈论的Visual Studio的API是瓶颈。导致 Visual Studio 在整个过程中以 100％的CPU使用率达到峰值。

所以我想，如果Visual Studio那么慢，也许我可以在没有它的情况下做到这一点。令我失望的是NuGet命令行（没有Visual Studio运行）只下载一个包并解压缩它。它不会更新项目文件，因为一些Powershell脚本可以引用DTE对象...（虽然我没有）。

现在我想知道：我的选择是什么？

在项目文件上做一些XML-magic来添加内容项？这样做有什么缺点？是否已经有了这个工具？
使用构建脚本做一些魔术？
将内容文件从包中丢弃并使用其他工具，如Bower或其他东西？如何将其整合到项目中？因为最终我想看到我的内容文件。
根本不使用NuGet而是其他东西......？ OpenWrap？喇叭？（似乎不再活跃）或者根本没有包管理器？

请帮我找到最佳解决方案：）

让我感到沮丧的另一件事是，在执行NuGet更新时，它会执行卸载，然后执行安装。为什么，如果版本之间的变化可能很小？

Answer 1

一个选项是，您可以将它们作为资源嵌入共享库中，而不是添加800个内容文件。

然后使用类似EmbeddedResourceVirtualPathProvider https://github.com/mcintyre321/EmbeddedResourceVirtualPathProvider的内容来提供服务。

这样NuGet只是替换.dll而不是800个单独的文件。

网上有很多关于如何使用VirtualPathProvider的文章。

编辑：有关效果的问题

解决方案似乎相对简单，所以我只是尝试一下，看看性能是否可以接受。好消息是，您不必对Web应用程序中的路径执行任何特殊操作。

以下是您需要执行的步骤：

在资源库中，将内容文件设置为嵌入资源。您可以通过在文本编辑器中打开 .csproj 文件并将<Content替换为<EmbeddedResource来快速完成此操作。
向您的网络应用添加对资源库的引用。
将EmbeddedResourceVirtualPathProvider NuGet包添加到您的网络应用
注册虚拟路径提供程序。以下是使用存储在AppInitialize()文件夹中的App_Code进行注册的示例。

namespace TestWebProject.App_Code
{
    public class RegisterVirtualPathProvider
    {
        public static void AppInitialize()
        {
            HostingEnvironment.RegisterVirtualPathProvider(new EmbeddedResourceVirtualPathProvider.Vpp()
            {
                {typeof (Marker).Assembly, @"..\TestResourceLibrary"},

            });
        }
    }
}

使用NuGet的内容文件非常慢

1 个答案: