asp.net home wiki 出现表示可以通过“bin”包装器添加对本地生成的 dll（程序集）的引用。但是，project.json 文件中似乎只能包含一个 bin 包装器。那么，添加对针对 .net framework 4.6 和可移植库 .net framework 4.6 编译的外部类库 dll 的引用的正确方法是什么？
顺便说一句。这些 DLL 与 ASP.Net 项目不在同一个解决方案中。
【问题讨论】：
标签： .net asp.net-core
这里是wikihttps://github.com/aspnet/Home/wiki/Project.json-file#bin-syntax-wrapping-a-dll中“bin语法”的准确位置
维基上写着：
您可以创建一个项目，而不是编译，而是引用已编译的 dll 并生成包含该 dll 的包
请注意，使用“bin 语法”，您正在创建一个使用包装好的 dll 作为其输出的项目（而不是编译一些源代码来获取输出 dll）。您没有添加 dll 作为目标 project.json 的引用。
以下是当您要添加对 dll 的引用时使用“bin 语法”的正确方法的示例：
假设我们有：
要添加从 ProjectA 到 ClassLibraryB.dll 的引用，我们需要创建一个包装 ClassLibraryB.dll 的包装器项目：
在 ClassLibraryB 文件夹中创建一个 project.json，内容如下：
{
"frameworks": {
"dnx451": {
"bin": {
"assembly": "<path to ClassLibraryB.dll>"
}
}
}
}
【讨论】：
将近一年后，我能够获得对包含和编译的非本地 dll 的引用。需要遵循一些缺失和误解的步骤。
在过去一年的旅程中，我找不到许多以前命名的 DNX 实用程序版本。就在最近，我发现一篇文章说您必须运行 DNVM 才能选择运行时的版本。完成后，DNX 的路径将放置在路径变量中。不要忘记在此时启动 CMD（或 PowerShell）的新副本以获取新的环境变量。另请注意，.dnx 文件夹是隐藏文件夹，除非您关闭隐藏隐藏文件夹，否则不会使用 dir 命令或在 Windows 资源管理器中显示。有关运行 DNVM 的更多讨论，请参阅 Stack Overflow question "DNX does not work"。
设置好 dnx 环境后，就可以运行 dnu wrap。第一个问题是您必须在解决方案文件夹中有一个 global.json 文件。默认情况下不会创建此文件，并且其中应该包含的文档几乎不存在。该文件需要包含最少的信息。
{
"projects": [
"web"
],
"sdk": {
"version": "1.0.0-rc1-update1",
"runtime": "clr",
"architecture": "x86"
}
}
在我的示例中，web 是解决方案中唯一项目的名称。其他可根据需要添加。创建后，将解决方案目录设为当前目录，然后发出 dnu wrap 命令。
dnu wrap full_path_to_an_assembly -f framework_version
说实话，我不完全确定框架版本可以/应该包含什么。我使用了 dnx461，因为那是我编译 dll 所针对的框架版本。 dnu wrap 操作的输出将进入解决方案文件夹下的“wrap”文件夹，并且 global.json 文件将被更新以将 wrap 项目（文件夹）包含在项目部分中。
由于在每个新解决方案中包含多个 dll 似乎需要做很多工作，因此我手动创建了用于包装的 project.json 文件并将它们放置在全局位置（就在普通 .net 程序集旁边）会参考他们）。然后，我将该文件夹的完整路径作为项目放在 global.json 文件中，我能够添加引用并进行编译。一个问题是，即使支持相对路径，但对于它们的相对路径似乎也存在一些混淆。我必须在提供二进制包装的 project.json 文件中包含二进制文件（和 pdb）的完整路径。 用于包装二进制文件的示例 project.json
{
"version": "1.0.0-*",
"frameworks": {
"dnx461": {
"bin": {
"assembly": "../../bin/log4net.dll"
}
}
}
}
注意上面相对路径的使用。那不能正常工作。将其更改为相关程序集的完整路径。
好消息是，一旦一切设置正确，Visual Studio 中 project.json 的依赖项部分的智能感知将在您键入时指示 dll 的名称。
【讨论】：