在asp.net家维基 似乎表明，人们可以通过“bin”的包装增加当地生产的DLL（组件）的引用。但是，看来project.json文件中可能仅包含一个bin包装器。那么，将引用添加到针对.net framework 4.6和可移植库.net framework 4.6编译的外部类库dll的正确方法是什么？
顺便提一句。这些DLL与ASP.Net项目不在同一解决方案中。
将近一年之后，我能够获得对包含和编译的非本地dll的引用。需要遵循一些遗漏和误解的步骤。
在过去的一年中，我找不到许多以前命名的DNX实用程序版本。就在最近，我发现了一篇文章，说您必须运行DNVM才能选择运行时的版本。完成后，将DNX的路径放置在path变量上。别忘了在那时启动新的CMD（或PowerShell）副本以选择新的环境变量。另请注意，.dnx文件夹是隐藏文件夹，除非您已关闭隐藏隐藏文件夹，否则不会使用dir命令或在Windows资源管理器中显示。有关运行DNVM的更多讨论，请参见堆栈溢出问题“ DNX不起作用”。
设置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操作的输出将进入solution文件夹下的“ wrap”文件夹，并且global.json文件将被更新以在项目部分中包括wrap项目（文件夹）。
由于在每个新解决方案中都包含多个dll的过程似乎很繁琐，因此我手动创建了用于包装的project.json文件，并将其放置在全局位置（在旁边是普通.net程序集引用它们的位置） ）。然后，我将该文件夹的完整路径作为一个项目放置在global.json文件中，并且能够添加引用并进行编译。一个问题是，即使支持相对路径，它们之间的相对关系似乎也有些混乱。我必须在提供二进制包装的project.json文件中包括二进制文件（和pdbs）的完整路径。示例project.json用于包装二进制文件
{
"version": "1.0.0-*",
"frameworks": {
"dnx461": {
"bin": {
"assembly": "../../bin/log4net.dll"
}
}
}
}
注意上面相对路径的使用。那不能正常工作。将其更改为有关程序集的完整路径。
好消息是，一旦一切设置正确，Visual Studio中的project.json依赖项部分的intellisense将在您键入dll时指示该dll的名称。
本文收集自互联网，转载请注明来源。
如有侵权，请联系[email protected] 删除。
我来说两句