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

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

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

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

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

对项目文件执行一些XML魔术来添加内容项？这样做的缺点是什么？已经有这样的工具了吗

用构建脚本做一些魔术

扔掉软件包中的内容文件，使用其他工具，比如Bower或其他什么？如何将其整合到项目中？因为最终我希望看到我拥有的内容文件

不使用NuGet，但使用其他东西。。。？开放包装？喇叭（似乎不再处于活动状态）或者根本没有包管理器

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

---

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

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

然后使用类似于

EmbeddedResourceVirtualPathProvider

的方法为它们提供服务

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

网上有很多关于如何使用

VirtualPathProvider

的文章

编辑：有关性能的问题

解决方案似乎相对简单，所以我会尝试一下，看看性能是否可以接受。很好的一点是，您不必对web应用程序中的路径做任何特殊的处理

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

---

在资源库中，将内容文件设置为嵌入式资源。通过在文本编辑器中打开.csproj文件并替换

听起来是一个不错的解决方案，您可以很快做到这一点。使用此选项有任何缺点吗？像最终用户可能出现的性能滞后吗？更新了答案，并提供了更多信息info@sebas2day，存在性能问题，由于整个程序集都在内存中，它会占用更多内存，并且应用程序的加载速度会较慢，IIS不会将其缓存为静态内容，IIS也不会将其压缩为静态内容压缩，您将在运行时使用更多的cpu。