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

查看:117
本文介绍了.Net Core 3.0 NuGet DLL的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

假设我们在Console .Net Core应用程序中包含Nuget包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个使用相同软件包的控制台应用程序,则这些dll将位于应用程序服务器中的10个不同文件夹中。如果我们引用多个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。

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文件夹中。 ,同时使用公共DLL文件夹的新位置路径更新 .deps.json 文件和 .runtimeconfig.json 文件和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.

想法是枚举publish文件夹中的DLL,并将这些文件名存储在collection / dictionary中,随后再使用该字典来更新中的运行时dll路径。 deps.json。对于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 Profile包含一个我们可以指定的文件夹,其中所有除了Publish文件夹外,还将驻留第三方和Nuget程序包DLL,其中仅将驻留应用程序可执行文件,app 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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆