使用NuGet的内容文件非常非常慢

本文关键字：非常 文件 NuGet 使用 | 更新日期: 2023-09-27 18:00:37

我有一个由多个站点共享的通用ASP.NET web应用程序。我使用NuGet来打包这个常见的web应用程序，并将其分发到多个网站上。遵循这个想法：多个ASP.NET web应用程序依赖于一个通用的基础应用程序。

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

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

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

  1. 对项目文件执行一些XML魔术以添加内容项？这样做的缺点是什么？已经有这样的工具了吗
  2. 用构建脚本变魔术
  3. 扔掉包中的内容文件，然后使用Bower之类的其他工具？如何将其整合到项目中？因为最终我想看到我拥有的内容文件
  4. 根本不使用NuGet，而是使用其他东西。。。？OpenWrap？喇叭（似乎不再活动）或者可能根本没有包管理器

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

另一件让我沮丧的事情是，在执行NuGet更新时，它先卸载，然后安装。为什么，如果版本之间的更改可以是最小的？

使用NuGet的内容文件非常非常慢

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

然后使用类似EmbeddedResourceVirtualPathProvider的东西https://github.com/mcintyre321/EmbeddedResourceVirtualPathProvider把它们端上来。

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

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

编辑：有关性能的问题

这个解决方案看起来相对简单，所以我会尝试一下，看看性能是否可以接受。好的是，你不必对你的网络应用程序中的路径做任何特别的事情。

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

  1. 在资源库中，将内容文件设置为嵌入式资源。您可以通过在文本编辑器中打开.csproj文件并将<Content替换为<EmbeddedResource来快速完成此操作
  2. 将对资源库的引用添加到web应用程序中
  3. 将EmbeddedResourceVirtualPathProvider NuGet包添加到您的web应用程序中
  4. 注册虚拟路径提供程序。以下是使用存储在App_Code文件夹中的AppInitialize()进行注册的示例
namespace TestWebProject.App_Code
{
    public class RegisterVirtualPathProvider
    {
        public static void AppInitialize()
        {
            HostingEnvironment.RegisterVirtualPathProvider(new EmbeddedResourceVirtualPathProvider.Vpp()
            {
                {typeof (Marker).Assembly, @"..'TestResourceLibrary"},
            });
        }
    }
}
相关文章：