如何诊断dnx中缺少依赖项(或其他加载程序故障)?


133

我正在尝试使用Kestrel在DNX上为ASP.NET vNext 运行HelloWeb示例的修改版本。我知道这是非常前沿的,但是我希望ASP.NET团队至少能够保持最简单的Web应用程序正常工作:)

环境:

  • Linux(Ubuntu,差不多)
  • 单声道3.12.1
  • DNX 1.0.0-beta4-11257(我也有11249个可用)

“ Web应用”代码,位于Startup.cs

using Microsoft.AspNet.Builder;
public class Startup
{
    public void Configure(IApplicationBuilder app)
    {
        app.UseWelcomePage();
    }
}

项目配置,位于project.json

{
  "dependencies": {
    "Kestrel": "1.0.0-beta4",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta4",
    "Microsoft.AspNet.Hosting": "1.0.0-beta4",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta4",
    "Microsoft.AspNet.StaticFiles": "1.0.0-beta4",
    "Microsoft.Framework.Runtime": "1.0.0-beta4",
    "Microsoft.Framework.Runtime.Common": "1.0.0-beta4",
    "Microsoft.Framework.Runtime.Loader": "1.0.0-beta4",
    "Microsoft.Framework.Runtime.Interfaces": "1.0.0-beta4",
  },
  "commands": {
    "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
  },
  "frameworks": {
    "dnx451": {}
  }
}

kpm restore 看起来工作正常。

但是,当我尝试运行时,出现异常提示Microsoft.Framework.Runtime.IApplicationEnvironment找不到该异常。命令行和错误(已重新格式化)

.../HelloWeb$ dnx . kestrel
System.IO.FileNotFoundException: Could not load file or assembly 
'Microsoft.Framework.Runtime.IApplicationEnvironment,
  Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
or one of its dependencies.
File name: 'Microsoft.Framework.Runtime.IApplicationEnvironment,
  Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
  at (wrapper managed-to-native) System.Reflection.MonoMethod:InternalInvoke 
    (System.Reflection.MonoMethod,object,object[],System.Exception&)
  at System.Reflection.MonoMethod.Invoke 
    (System.Object obj, BindingFlags invokeAttr, System.Reflection.Binder binder,
     System.Object[] parameters, System.Globalization.CultureInfo culture)
    [0x00000] in <filename unknown>:0

显然,我最迫切的需要是解决此问题,同时,我也非常感谢您提供有关如何逐步诊断出问题的建议,以便将来自己解决类似的问题。(这也可能使这个问题对其他人也更有用。)

我已经Microsoft.Framework.Runtime.IApplicationEnvironmentMicrosoft.Framework.Runtime.InterfacesAssembly Source中找到了,并且最近似乎没有改变。目前尚不清楚为什么异常将名称显示为本身是一个完整的程序集,而不仅仅是另一个程序集内的接口。我猜想这可能是由于程序集中立接口引起的,但是从错误中还不清楚。[AssemblyNeutral]已经死了,不是吗...


出于好奇,您是要链接到github.com/aspnet/Home/wiki/Assembly-Neutral-Interfaces以获得您的装配中立接口链接还是其他地方?由于它目前已损坏
cgijbels 2015年

@cgijbels:谢谢-我实际上是想链接到davidfowl.com/assembly-neutral-interfaces,但您的链接可能更好……
Jon Skeet

@JonSkeet程序集的中立接口现在不见了。
tugberk

@tugberk:天哪,真的吗?很有意思-您是否有一个链接可以包含在编辑中?
乔恩·斯基特

Answers:


144

好问题。对于您的特定问题,看来您解决的依赖性不匹配。当发生这种情况时,可能是因为您在不兼容的dnx上运行应用程序。我们仍在进行重大更改,因此,如果您发现缺少缺少类型的方法,则有可能您最终运行了betaX程序包,并且betaY dnx则相反。

更具体地说,装配中性接口在Beta4中已删除了,但看起来您正在运行的应用程序仍在使用它们。

我们计划这样做,以便程序包可以标记它们需要运行的最小dnx,以使错误消息更加清晰。而且随着时间的流逝,重大变化将消失。

总的来说,我觉得是时候我写了一篇指南,介绍如何在使用dnx时诊断此类问题(因为它与现有的.NET完全不同)。

您放入的依赖性project.json仅是顶级的。版本也始终是最低版本(就像NuGet包一样)。这意味着当您指定时,Foo 1.0.0-beta4您实际上是在指定Foo >= 1.0.0-beta4。这意味着,如果您要求MVC 0.0.1并且配置的供稿上的最低版本为MVC 3.0.0,那么您将获得该版本。除非您指定版本,否则我们也绝不会浮动您的版本。如果要求1.0.0并且存在,那么即使存在较新的版本,也将获得1.0.0。指定空版本总是不好的,在以后的版本中将不允许使用。

我们正在为nuget引入一个新功能,称为浮动版本。今天,它仅适用于prerelease标签,但在下一版本中,它将适用于该版本的更多部分。这类似于npm和gem语法,用于在软件包规范文件中指定版本范围。

1.0.0-*-意味着给我最高前缀匹配的版本(根据语义版本控制规则),或者如果没有与该前缀匹配的版本,请使用正常的行为,让我最低版本> =指定的版本。

在最新版本中运行还原时,它将写出一个名为的文件project.lock.json。该文件将对中定义的所有目标框架的依赖项进行传递性关闭project.json

当类似的操作失败时,您可以执行以下操作:

看看使用 kpm list。这将向您显示项目引用的已解析软件包的版本以及将其引入哪个依赖项。例如,如果A-> B,它将显示:

一个
  -> B
乙
 ->

实际KPM列表输出:

列出ClassLibrary39的依赖项(C:\ Users \ davifowl \ Documents \ Visual Studio 14 \ Projects \ ClassLibrary39 \ src \ ClassLibrary39 \ project.json)

[Target framework DNX,Version=v4.5.1 (dnx451)]

 framework/Microsoft.CSharp 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/mscorlib 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/System 4.0.0.0
    -> ClassLibrary39 1.0.0
 framework/System.Core 4.0.0.0
    -> ClassLibrary39 1.0.0
*Newtonsoft.Json 6.0.1
    -> ClassLibrary39 1.0.0

[Target framework DNXCore,Version=v5.0 (dnxcore50)]

*Newtonsoft.Json 6.0.1
    -> ClassLibrary39 1.0.0
 System.Runtime 4.0.20-beta-22709
    -> ClassLibrary39 1.0.0

*表示直接依赖。

如果您有一个正在运行的Visual Studio(目前已与DNX分离),则可以查看参考节点。它具有以视觉方式表示的相同数据:

参考节点

让我们看一下依赖失败的样子:

这是project.json

{
    "version": "1.0.0-*",
    "dependencies": {
        "Newtonsoft.Json": "8.0.0"
    },

    "frameworks" : {
        "dnx451" : { 
            "dependencies": {
            }
        },
        "dnxcore50" : { 
            "dependencies": {
                "System.Runtime": "4.0.20-beta-22709"
            }
        }
    }
}

Newtonsoft.Json 8.0.0不存在。因此,运行kpm restore将显示以下内容:

在此处输入图片说明

当诊断还原何时可能失败时,请查看发出的HTTP请求,它们会告诉您kpm查找了哪些已配置的软件包源。请注意,在上图中,有一个CACHE请求。这是基于资源类型(nupkg或nuspec)的内置缓存,并且具有可配置的TTL(请参阅参考资料kpm restore --help)。如果要强制kpm访问远程NuGet源,请使用--no-cache标志:

KPM恢复-无缓存

这些错误也会显示在Visual Studio的程序包管理器日志输出窗口中:

在此处输入图片说明

边注!

包裹来源

我将描述NuGet.config现在的工作方式(将来可能会改变)。默认情况下,您具有一个NuGet.config,其中默认的NuGet.org源在以下位置进行了全局配置%appdata%\NuGet\NuGet.Config。您可以在Visual Studio中或使用NuGet命令行工具管理这些全局源。在诊断故障时,应始终查看有效的来源(在kpm输出中列出的来源)。

在此处阅读有关NuGet.config的更多信息

回到现实:

当依赖关系无法解决时,运行该应用程序将为您提供:

> dnx . run
System.InvalidOperationException: Failed to resolve the following dependencies for target framework 'DNX,Version=v4.5.1':
   Newtonsoft.Json 8.0.0

Searched Locations:
  C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\{name}\project.json
  C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\test\{name}\project.json
  C:\Users\davifowl\.dnx\packages\{name}\{version}\{name}.nuspec
  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\{name}.dll
  C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Facades\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_32\{name}\{version}\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_64\{name}\{version}\{name}.dll
  C:\WINDOWS\Microsoft.NET\assembly\GAC_MSIL\{name}\{version}\{name}.dll

Try running 'kpm restore'.

   at Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)
   at Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)
   at Microsoft.Framework.ApplicationHost.Program.Main(String[] args)

运行时基本上在尝试运行之前尝试验证是否已解决整个依赖关系图。如果它建议运行,kpm restore那是因为它找不到列出的依赖项。

您可能会收到此错误的另一个原因是,如果您运行的是错误的dnx风格。如果您的应用程序仅指定dnx451,并且您尝试运行CoreCLR dnx,则可能会遇到类似的问题。请密切注意错误消息中的目标框架:

运行:

dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}

当您尝试运行时,应该记住从clr到您的中定义的目标框架的思维导图project.json

这也显示在Visual Studio的“引用”节点下: 未解决的依赖关系

标记为黄色的节点尚未解析。

这些也会显示在错误列表中:

错误列表未解决的依赖性

建造

在构建时也会显示这些错误。从命令行进行构建时,输出非常冗长,并且在诊断问题时非常有用:

> kpm build

Building ClassLibrary39 for DNX,Version=v4.5.1
  Using Project dependency ClassLibrary39 1.0.0
    Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json

  Using Assembly dependency framework/mscorlib 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll

  Using Assembly dependency framework/System 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.dll

  Using Assembly dependency framework/System.Core 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\System.Core.dll

  Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
    Source: C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\Microsoft.CSharp.dll


Building ClassLibrary39 for DNXCore,Version=v5.0
  Using Project dependency ClassLibrary39 1.0.0
    Source: C:\Users\davifowl\Documents\Visual Studio 14\Projects\ClassLibrary39\src\ClassLibrary39\project.json

  Using Package dependency System.Console 4.0.0-beta-22709
    Source: C:\Users\davifowl\.dnx\packages\System.Console\4.0.0-beta-22709
    File: lib\contract\System.Console.dll

  Using Package dependency System.IO 4.0.10-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.IO\4.0.10-beta-22231
    File: lib\contract\System.IO.dll

  Using Package dependency System.Runtime 4.0.20-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.Runtime\4.0.20-beta-22231
    File: lib\contract\System.Runtime.dll

  Using Package dependency System.Text.Encoding 4.0.10-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.Text.Encoding\4.0.10-beta-22231
    File: lib\contract\System.Text.Encoding.dll

  Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
    Source: C:\Users\davifowl\.dnx\packages\System.Threading.Tasks\4.0.10-beta-22231
    File: lib\contract\System.Threading.Tasks.dll

输出显示了从程序包和项目引用传递到编译器的所有程序集。当您开始遇到构建失败时,查看此处以确保您使用的软件包在该目标平台上确实有效是很有用的。

这是在dnxcore50上不起作用的软件包的示例:

{
    "version": "1.0.0-*",
    "dependencies": {
        "Microsoft.Owin.Host.SystemWeb": "3.0.0"
    },

    "frameworks": {
        "dnx451": {
            "dependencies": {
            }
        },
        "dnxcore50": {
            "dependencies": {
                "System.Console": "4.0.0-beta-22709"
            }
        }
    }
}

Microsoft.Owin.Host.SystemWeb版本3.0.0没有在dnxcore50上运行的任何程序集(请查看解压缩后的程序包的lib文件夹)。当我们运行时kpm build

dnxcore50上缺少程序集

注意它说“使用包Microsoft.Owin.Host.SystemWeb”,但没有“文件:”。这可能是构建失败的原因。

到此为止我的脑力激荡


我正在尝试按照您的建议使用dnu列表,以确定dnx无法解析依赖项的原因。但是我收到一个红色的“无法找到project.json”。程序集在工件文件夹中,该文件夹通过选中“在生成时生成输出”生成。有关如何进行的任何建议?
Mike Scott

工件文件夹与什么有什么关系?您是否在project.json中引用了依赖项?您所引用的程序包在配置的提要中可用吗?
davidfowl 2015年

17

我仍然不知道完全什么是错的,但是我现在有一系列的措施,至少使其更容易尝试的事情:

  • 如有疑问,请重新安装dnx
    • 吹走软件包缓存可能会有所帮助
  • 检查~/.config/NuGet.config以确保您使用正确的NuGet提要

我最终使用以下命令行以相当干净的方式测试了各种选项:

rm -rf ~/.dnx/packages && rm -rf ~/.dnx/runtimes && dnvm upgrade && kpm restore && dnx . kestrel

看来我的问题确实是由于所安装依赖项的版本错误造成的。的版本号"1.0.0-beta4"显然与完全不同"1.0.0-beta4-*"。例如,Kestrel依赖项仅在指定为时安装了1.0.0-beta4-11185 1.0.0-beta4版本,但-*在末尾带有1.0.0-beta4-11262版本。我想beta4明确指定以避免将beta3版本与

以下项目配置可以正常运行:

{
  "dependencies": {
    "Kestrel": "1.0.0-beta4-*",
    "Microsoft.AspNet.Diagnostics": "1.0.0-beta4-*",
    "Microsoft.AspNet.Hosting": "1.0.0-beta4-*",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta4-*",
  },
  "commands": {
    "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
  },
  "frameworks": {
    "dnx451": {}
  }
}

6
这是因为-*始终为您提供最新的预发行版本,而没有它,您将得到满足所有依赖关系的最低版本(与NuGet一样)。该测试有一些示例。
AlexanderKöplinger15年

2
@AlexanderKöplinger:谢谢,这很有道理。所以... beta4是最早的beta4,而... beta4- *是最新的beta4,对吗?
乔恩·斯基特

4
"frameworks": {"dnx451": {}}是否已为我修复此问题,无需dnxcore50
vicentedealencar 2015年

您的第一个命令还帮助我摆脱了beta5版本的困扰。我尝试运行dnvm upgrade-self,这不会升级到最新版本。以admin身份运行VS命令提示符时,显示dnvm版本为dnv rc1...,但是以admin身份运行时,则为dnvm版本beta5...。执行命令后,admin和非admin命令提示符都显示为rc2...(最新)版本。
JabberwockyDecompiler 2015年

对于那些使用Mono并想选择dnx451还是dnxcore50回答这个问题的人,它们使我更加了解了此主题:stackoverflow.com/a/30846048/89590简短答案:dnx451适用于Mono。
Nate Cook

8

您可以设置一个名为的环境变量DNX_TRACE1看看一吨多的诊断信息。被警告,这是一个很大的详细信息!


@JonSkeet顺便说一句,其他答案(包括您的自我答案)包含有关诊断和修复您遇到的特定问题的重要信息。我将这个答案简短地讲了一下,因为这只是另一个不同的答案,可能会导致更多有关该问题为什么首先发生的线索。
艾隆2015年

绝对-非常感谢:)
乔恩·斯凯特

3

为了使其正常工作,我修改了我的project.json..现在它看起来像:

{
"dependencies": {
    "Kestrel": "1.0.0-*",
    "Microsoft.AspNet.Diagnostics": "1.0.0-*",
    "Microsoft.AspNet.Hosting": "1.0.0-*",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-*",
    "Microsoft.AspNet.StaticFiles": "1.0.0-*"
},
"commands": {
    "web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://localhost:5001",
    "kestrel": "Microsoft.AspNet.Hosting --server Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
    }
}

关键似乎是框架部分。

同样,重命名更改了k web工作方式,以便现在dnx . webdnx . kestrel

更新-更多信息

奇怪的是,在没有定义任何框架的情况下运行时,当我这样做时,它又得到了很多额外的东西kpm restore

...
Installing Microsoft.Framework.Logging 1.0.0-beta4-11001
Installing Microsoft.Framework.Logging.Interfaces 1.0.0-beta4-11001
Installing Microsoft.Framework.DependencyInjection.Interfaces 1.0.0-beta4-11010
Installing Microsoft.Framework.DependencyInjection 1.0.0-beta4-11010
Installing Microsoft.Framework.ConfigurationModel 1.0.0-beta4-10976
Installing Microsoft.Framework.ConfigurationModel.Interfaces 1.0.0-beta4-10976
Installing Microsoft.AspNet.Hosting.Interfaces 1.0.0-beta4-11328
Installing Microsoft.AspNet.FeatureModel 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http 1.0.0-beta4-11104
Installing Microsoft.AspNet.FileProviders.Interfaces 1.0.0-beta4-11006
Installing Microsoft.Framework.Caching.Interfaces 1.0.0-beta4-10981
Installing Microsoft.AspNet.FileProviders 1.0.0-beta4-11006
Installing Microsoft.AspNet.Http.Core 1.0.0-beta4-11104
Installing Microsoft.AspNet.WebUtilities 1.0.0-beta4-11104
Installing Microsoft.Net.Http.Headers 1.0.0-beta4-11104
Installing Microsoft.AspNet.Http.Interfaces 1.0.0-beta4-11104
Installing Microsoft.Framework.Runtime.Interfaces 1.0.0-beta4-11257
Installing Microsoft.AspNet.Server.Kestrel 1.0.0-beta4-11262
Installing Microsoft.Net.Http.Server 1.0.0-beta4-11698
Installing Microsoft.Net.WebSockets 1.0.0-beta4-11698
Installing Microsoft.Net.WebSocketAbstractions 1.0.0-beta4-10915
Installing Microsoft.Framework.WebEncoders 1.0.0-beta4-11104
Installing Microsoft.Framework.OptionsModel 1.0.0-beta4-10984
Installing Microsoft.AspNet.Http.Extensions 1.0.0-beta4-11104
Installing Microsoft.AspNet.Diagnostics.Interfaces 1.0.0-beta4-12451
Installing Microsoft.AspNet.RequestContainer 1.0.0-beta4-11328

..然后运行良好。然后我切换回框架部分

"frameworks": {
    "dnx451": {}
}

..并且它仍然有效,但是在它抛出错误之前!

很奇怪!

(我正在跑步1.0.0-beta4-11257

进一步更新

我启动了一个新的Ubuntu实例,并遇到了与您相同的错误..我想这个问题可能是由于它仅试图从中获取软件包nuget.org而没有myget.org(它具有较新的东西)导致的,所以我将其NuGet.Config放入了项目的根

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <packageSources>
    <add key="AspNetVNext" value="https://www.myget.org/F/aspnetvnext/" />
    <add key="NuGet" value="https://nuget.org/api/v2/" />
  </packageSources>
</configuration>

..这似乎已经通过获取正确的版本(一个接一个kpm restore)为我修复了它。


1
重新“ dnx。kestrel”部分-实际上,因此,我显示的命令是:)使用该配置,我得到了另一个错误:System.TypeLoadException:无法从程序集“ Microsoft”中加载类型“ Microsoft.Framework.DependencyInjection.LoggingServiceCollectionExtensions”。 Framework.Logging,版本= 1.0.0.0,文化=中性,PublicKeyToken =空'。您正在使用哪个版本的DNX?
乔恩·斯基特

1
当我第一次做“ dnx .web”时,我得到:`System.InvalidOperationException:无法解决目标框架'DNX,Version = v4.5.1'的以下依赖关系,并且它建议了它所缺少的东西的清单。
Stephen Pope

有趣。顺便说一句,这是在什么平台上?
乔恩·斯基特

升级DNX之后,是否执行了“ source〜/ .bashrc”来重新加载环境变量?我还必须做“ dnvm升级” +“ dnvm使用默认设置”
Stephen Pope

DNX尚未通过.bashrc更新...可能是因为我昨天手动构建了它。将尝试改用更新的说明...
Jon Skeet 2015年

2

这些天,我所有的package.json版本都以"-rc2-*"

(到目前为止,只有我所看到的例外是Microsoft.Framework.Configuration软件包,它们必须是"1.0.0-rc1-*""1.0.0-*"

关于@davidfowl提到的“版本训练”,似乎在beta8和rc2之间已经消失了很多痛苦。

dnvm upgrade -u -arch x64 -r coreclr

我最幸运的是coreclr这两个NuGet提要:

"https://www.myget.org/F/aspnetvnext/"
"https://nuget.org/api/v2/"

当我确实缺少包装问题时,有90%的时间是同样的原因:

Newtonsoft.Json
Ix-Async
Remotion.Linq

在大多数情况下,我可以通过强制NuGet.org主提要来解决这些问题:

dnu restore;
dnu restore -s https://nuget.org/api/v2

这是我的工作config.json:

{
"dependencies": {
    "Microsoft.AspNet.Diagnostics": "1.0.0-rc2-*",
    "Microsoft.AspNet.Diagnostics.Entity": "7.0.0-rc2-*",
    "Microsoft.AspNet.Hosting": "1.0.0-rc2-*",
    "Microsoft.AspNet.Http": "1.0.0-rc2-*",
    "Microsoft.AspNet.Http.Abstractions": "1.0.0-rc2-*",
    "Microsoft.AspNet.Mvc.Core": "6.0.0-rc2-*",
    "Microsoft.AspNet.Mvc.Razor": "6.0.0-rc2-*",
    "Microsoft.AspNet.Owin": "1.0.0-rc2-*",
    "Microsoft.AspNet.Routing": "1.0.0-rc2-*",
    "Microsoft.AspNet.Server.Kestrel": "1.0.0-rc2-*",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-rc2-*",
    "Microsoft.AspNet.Session": "1.0.0-rc2-*",
    "Microsoft.AspNet.StaticFiles": "1.0.0-rc2-*",
    "EntityFramework.Commands": "7.0.0-rc2-*",
    "EntityFramework.Core": "7.0.0-rc2-*",
    "EntityFramework.InMemory": "7.0.0-rc2-*",
    "EntityFramework.MicrosoftSqlServer": "7.0.0-rc2-*",
    "EntityFramework.MicrosoftSqlServer.Design": "7.0.0-rc2-*",
    "EntityFramework.Relational": "7.0.0-rc2-*",
    "EntityFramework7.Npgsql": "3.1.0-beta8-2",
    "Microsoft.Extensions.Logging.Abstractions": "1.0.0-rc2-*",
    "Microsoft.Extensions.Logging.Console": "1.0.0-rc2-*",
    "Microsoft.Extensions.DependencyInjection": "1.0.0-rc2-*",
    "Microsoft.Extensions.DependencyInjection.Abstractions": "1.0.0-rc2-*",
    "Microsoft.Framework.Configuration.CommandLine": "1.0.0-*",
    "Microsoft.Framework.Configuration.EnvironmentVariables": "1.0.0-*",
    "Microsoft.Framework.Configuration.Json": "1.0.0-*"
},
"commands": {
    "ef": "EntityFramework.Commands",
    "dev": "Microsoft.AspNet.Hosting --ASPNET_ENV Development --server Microsoft.AspNet.Server.Kestrel --server.urls http://localhost:5004"
},
"frameworks": {
    "dnxcore50": {}
}
}

上面的列表不是来自config.json,而是来自project.json,但是我仍然不赞成,因为该列表为我提供了以前不知道的有用的依赖项。
罗恩C

1

在尝试安抚dnxcore50和dnx451引用时,我也遇到了依赖项丢失的问题。

如果我理解这一权利,“依赖关系”:{}在框架之间共享。

然后,“框架”内的“依赖项”:{}:特定于该框架。

dnxcore50是模块化运行时(自包含),因此它基本上包含运行程序所需的所有核心运行时,而经典.net框架不同于在其他地方分散有核心依存关系的经典.net框架。

因此,我想坚持采用最小的方法,以防万一我决定在Mac或Linux上托管。

更新资料 Ran为具有cshtml视图的怪异依赖关系问题,目前仅与dnx451一起使用。

这是我的project.json

{
"webroot": "wwwroot",
"version": "1.0.0-*",

"dependencies": {
    "System.Runtime": "4.0.10",
    "Microsoft.AspNet.Hosting": "1.0.0-beta4",
    "Microsoft.AspNet.Mvc": "6.0.0-beta4",
    "Microsoft.AspNet.Server.IIS": "1.0.0-beta6-12075",
    "Microsoft.AspNet.Server.WebListener": "1.0.0-beta6-12457",
    "Microsoft.Framework.DependencyInjection": "1.0.0-beta4",
    "Microsoft.Framework.DependencyInjection.Interfaces": "1.0.0-beta5"
 },

"commands": {
"web": "Microsoft.AspNet.Hosting --server Microsoft.AspNet.Server.WebListener --server.urls http://admin.heartlegacylocal.com"  },

"frameworks": {
"dnx451": { }
 }
},

"publishExclude": [
"node_modules",
"bower_components",
"**.xproj",
"**.user",
"**.vspscc"
],
"exclude": [
  "wwwroot",
  "node_modules",
  "bower_components"
  ]
}
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.