.Net Core 3.0 NuGet DLL [英] .Net Core 3.0 NuGet DLLs

问题描述

假设我们在 Console .Net Core 应用程序中包含 Nuget Package Microsoft.Extensions.Configuration，并在另一个 Console .Net Core 应用程序中包含相同的包.

Let's say that we include Nuget Package Microsoft.Extensions.Configuration in a Console .Net Core app, and include the same package in another Console .Net Core app.

当我们发布这两个应用时，每个应用都会发布:

When we publish these two apps, each app would publish:

Microsoft.Extensions.Configuration.Abstractions.dll
Microsoft.Extensions.Configuration.dll

在每个文件夹中.

如果我们有 10 个控制台应用程序使用相同的包，我们将在应用程序服务器的 10 个不同文件夹中拥有这些 dll.如果我们引用多个 NuGet 包，依赖 dll 文件的数量会成倍增加.

If we had 10 console apps using the same package, we would have these dlls in 10 different folders in the application server. If we reference to multiple NuGet packages, the number of dependency dll files would multiply.

有没有办法将这些 dll 合并到应用服务器的一个文件夹中，所以当我们发布我们的可执行文件时，我们需要做的就是将可执行文件和配置文件移动到服务器，它会在一个文件夹中找到这些 dll公用文件夹.有点像设置 dll 路径.

Is there a way to consolidate these dlls in one folder in the app server, so when we publish our executable, all we need to do is move the executable and configuration file to the server, and it will find these dlls in a common folder. Sort of setting a dll Path.

推荐答案

考虑到 Trisped 的建议，我发布了一个我和我老板都不满意的答案.但目前就我所知，整合这些 DLL 的方法是编写一个实用程序，将这些 DLL 移动到指定的公共 DLL 文件夹中.和，同时将.deps.json文件和.runtimeconfig.json文件更新为通用DLL文件夹的新位置路径和 additionalProbingPaths 文件夹路径结构，分别.

In consideration of Trisped's suggestion, I am posting an answer that neither me nor my boss are completely satisfied with. But for the time being to the best of my knowledge, the way to consolidate these DLLs is by writing a utility program to move those DLLs to a designated common DLL folder. And, at the same time update both .deps.json file and .runtimeconfig.json file with the new location path of the common DLL folder and additionalProbingPaths folder path structure, respectively.

我们无法手动执行此操作，因为要移动的 DLL 过多，并且编辑 .deps.json 文件过于繁琐，每次我们发布控制台应用程序解决方案时这些文件都会被清除.我已经编写了实用程序.不幸的是，这是公司的 IP，所以我不能分享代码.

We can't do this by hand manually because there would be too many DLLs to move and too tedious to edit .deps.json file, which got wiped out everytime we publish the Console App solution. I have written the utility program. Unfortunately this is company's IP so I can't share the code.

这个想法是枚举发布文件夹中的 DLL 并将这些文件名存储在集合/字典中，然后使用该字典更新 .deps.json 中的运行时 dll 路径.对于 CLI 使用，我使用以下选项:

The idea is to enumerate the DLLs in the publish folder and store those filenames in a collection / dictionary, and later on use that dictionary to update the runtime dll paths in .deps.json. For CLI use, I use these options:

-c Release -f netcoreapp3.0 --self-contained false -r --runtime win-x64 -o <publisheFolder>

如果 Visual Studio 发布配置文件包含一个我们可以指定的文件夹，除了 Publish 文件夹之外，所有第三方和 Nuget 包 DLL 都将驻留在其中，这将非常有帮助，其中只有应用程序可执行文件、应用程序 dll、配置文件， deps.json 和 runtimeconfig.json 将驻留.如果 CLI 允许附加选项来指定 DLL 文件夹，并且在指示 --self-contained false 时不包括运行时文件夹，那就更好了.

It would be very helpful if Visual Studio Publish Profile would include a folder that we can specify, where all Third Party and Nuget Package DLLs will reside, in addition to the Publish folder, where only the app executable, app dll, configuration files, deps.json and runtimeconfig.json will reside. Even better if the CLI would allow additional option to specify the DLL folder and, not include the runtime folder when --self-contained false is indicated.

毕竟，DLL 的主要目的之一难道不是允许应用程序相互共享代码吗?

After all, isn't one of the main purpose of DLL to allow applications to share code with each other?

这篇关于.Net Core 3.0 NuGet DLL的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！