如何诊断 dnx 中缺少的依赖项(或其他加载程序故障)? [英] How can I diagnose missing dependencies (or other loader failures) in dnx?

查看:23
本文介绍了如何诊断 dnx 中缺少的依赖项(或其他加载程序故障)?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我正在尝试运行

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

回到现实:

当依赖项未解决时,运行应用程序会给你这个:

>dnx .跑System.InvalidOperationException:无法解决目标框架DNX,版本 = v4.5.1"的以下依赖项:Newtonsoft.Json 8.0.0搜索地点:C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39src{name}project.jsonC:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39	est{name}project.jsonC:Usersdavifowl.dnxpackages{name}{version}{name}.nuspecC:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1{name}.dllC:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1Facades{name}.dllC:WINDOWSMicrosoft.NETassemblyGAC_32{name}{version}{name}.dllC:WINDOWSMicrosoft.NETassemblyGAC_64{name}{version}{name}.dllC:WINDOWSMicrosoft.NETassemblyGAC_MSIL{name}{version}{name}.dll尝试运行kpm restore".在 Microsoft.Framework.Runtime.DefaultHost.GetEntryPoint(String applicationName)在 Microsoft.Framework.ApplicationHost.Program.ExecuteMain(DefaultHost host, String applicationName, String[] args)在 Microsoft.Framework.ApplicationHost.Program.Main(String[] args)

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

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

对于跑步:

dnx4x - 在 dnx-clr-{etc} 上运行dnxcore50 - 在 dnx-coreclr-{etc} 上运行

当您尝试运行时,您应该记住 project.json 中定义的从 clr 到目标框架的心理映射.

这也显示在 Visual Studio 的引用节点下:

标记为黄色的节点未解析.

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

建筑

这些错误在构建时也会出现.从命令行构建时,输出非常冗长,在诊断问题时非常有用:

>kpm 构建为 DNX 构建 ClassLibrary39,版本=v4.5.1使用项目依赖 ClassLibrary39 1.0.0来源:C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39srcClassLibrary39project.json使用程序集依赖框架/mscorlib 4.0.0.0来源:C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1mscorlib.dll使用程序集依赖框架/系统 4.0.0.0来源:C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1System.dll使用程序集依赖框架/System.Core 4.0.0.0来源:C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1System.Core.dll使用程序集依赖框架/Microsoft.CSharp 4.0.0.0来源:C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1Microsoft.CSharp.dll为 DNXCore 构建 ClassLibrary39,版本=v5.0使用项目依赖 ClassLibrary39 1.0.0来源:C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39srcClassLibrary39project.json使用包依赖 System.Console 4.0.0-beta-22709来源:C:Usersdavifowl.dnxpackagesSystem.Console4.0.0-beta-22709文件:libcontractSystem.Console.dll使用包依赖 System.IO 4.0.10-beta-22231来源:C:Usersdavifowl.dnxpackagesSystem.IO4.0.10-beta-22231文件:libcontractSystem.IO.dll使用包依赖 System.Runtime 4.0.20-beta-22231来源:C:Usersdavifowl.dnxpackagesSystem.Runtime4.0.20-beta-22231文件:libcontractSystem.Runtime.dll使用包依赖 System.Text.Encoding 4.0.10-beta-22231来源:C:Usersdavifowl.dnxpackagesSystem.Text.Encoding4.0.10-beta-22231文件:libcontractSystem.Text.Encoding.dll使用包依赖 System.Threading.Tasks 4.0.10-beta-22231来源:C:Usersdavifowl.dnxpackagesSystem.Threading.Tasks4.0.10-beta-22231文件:libcontractSystem.Threading.Tasks.dll

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

以下是一个不适用于 dnxcore50 的软件包示例:

{"版本": "1.0.0-*",依赖关系":{"Microsoft.Owin.Host.SystemWeb": "3.0.0"},构架": {dnx451":{依赖关系":{}},dnxcore50":{依赖关系":{System.Console":4.0.0-beta-22709"}}}}

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

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

我的脑残到此结束

I'm trying to run a modified version of the HelloWeb sample for ASP.NET vNext on DNX using Kestrel. I understand that this is very much on the bleeding edge, but I would hope that the ASP.NET team would at least keep the simplest possible web app working :)

Environment:

  • Linux (Ubuntu, pretty much)
  • Mono 3.12.1
  • DNX 1.0.0-beta4-11257 (I have 11249 available too)

"Web app" code, in Startup.cs:

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

Project config, in 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 appears to work fine.

When I try to run, however, I get an exception suggesting that Microsoft.Framework.Runtime.IApplicationEnvironment can't be found. Command line and error (somewhat reformatted)

.../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

While obviously, my most pressing need is to fix this, I'd also appreciate advice on how to move to diagnose what's going wrong so I can fix similar issues myself in the future. (That's also likely to make this question more useful to others, too.)

I've found Microsoft.Framework.Runtime.IApplicationEnvironment in the Microsoft.Framework.Runtime.Interfaces assembly source, and that doesn't appear to have changed recently. It's not clear why the exception shows the name as if it's a whole assembly in itself, rather than just an interface within another assembly. I'm guessing this may be due to assembly neutral interfaces, but it's not clear from the error. ([AssemblyNeutral] is dead, so that's not it...)

解决方案

Good question. For your specific problem, it looks like you have a mismatch in your resolved dependencies. When things like this happen it's likely because you're running your application on an incompatible dnx. We're still making very big breaking changes so if you ever see method missing of type missing, chances are you ended up running betaX packages and betaY dnx or vice versa.

Even more specifically, Assembly Neutral Interfaces were removed in beta4 but it looks like the application you are running is still using them.

We have plans to make it so that packages can mark the minimum dnx that they require to run to make the error message more clear. Also as time goes by, the breaking changes will die down.

In general though, I feel like it's time I wrote a guide on how to diagnose issues like this when using the dnx (since it's pretty different to existing .NET).

Dependencies you put into project.json are top level only. Versions are also always minimums (it's just like a NuGet package). This means that when you specify Foo 1.0.0-beta4 you're really specifying Foo >= 1.0.0-beta4. This means if you ask for MVC 0.0.1 and the minimum versions on your configured feed is MVC 3.0.0, you'll get that one. We also NEVER float your version unless you specify it. If you ask for 1.0.0 and it exists, you will get 1.0.0 even if newer versions exist. Specifying empty versions is ALWAYS bad and will be disallowed in later builds.

There's a new feature we're introducing to nuget called floating versions. Today it only works on the prerelease tag, but in the next version it'll work on more parts of the version. This is similar to npm and gem syntax for specifying version ranges in the package specification file.

1.0.0-* - Means give me the HIGHEST version matching the prefix (according to semantic versioning rules) OR if there is no version matching that prefix, use normal behavior and get me the LOWEST version >= the specified version.

When you run restore in the latest builds, it will write out a file called project.lock.json. This file will have the transitive closure of dependencies for all target frameworks defined in project.json.

When something like this fails you can do the following:

Take a look at the resolved dependencies using kpm list. This will show you the resolved versions of packages referenced by your project and what dependency pulled it in. e.g. if A -> B, it'll show:

A
  -> B
B
 ->

Actual KPM list output:

Listing dependencies for ClassLibrary39 (C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39srcClassLibrary39project.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

* means direct dependency.

If you have a working visual studio (which breaks with DNX right now), you can look at the references node. It has the same data represented visually:

Let's look at what a dependency failure looks like:

Here's the 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 doesn't exist. So running kpm restore shows the following:

When diagnosing when restore might have failed, look at the HTTP requests made, they tell you what configured package sources kpm looked in. Notice in the above image, there is a CACHE request. This is the built in caching based on the type of resource (nupkg or nuspec) and has a configurable TTL (look at kpm restore --help). If you want to force kpm to hit the remote NuGet sources, use the --no-cache flag:

These errors also show up in Visual Studio in the package manager log output window:

Side note!

Package Sources

I'll describe the way NuGet.config works right now (which will likely change in the future). By default you have a NuGet.config with the default NuGet.org source configured globally in %appdata%NuGetNuGet.Config. You can manage these global sources within visual studio or with the NuGet command line tool. You should always look at your effective sources (the ones listed in the kpm output) when trying to diagnose failures.

Read more about NuGet.config here

Back to reality:

When dependencies are unresolved, running the application will give you this:

> 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:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39src{name}project.json
  C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39	est{name}project.json
  C:Usersdavifowl.dnxpackages{name}{version}{name}.nuspec
  C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1{name}.dll
  C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1Facades{name}.dll
  C:WINDOWSMicrosoft.NETassemblyGAC_32{name}{version}{name}.dll
  C:WINDOWSMicrosoft.NETassemblyGAC_64{name}{version}{name}.dll
  C:WINDOWSMicrosoft.NETassemblyGAC_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)

The runtime basically tries to validate that the entire dependency graph is resolved before attempting to run. If it suggests running kpm restore it's because it can't find the dependencies listed.

Another reason why you might get this error is if you're running the wrong dnx flavor. If your application only specifies dnx451 and you try to run the CoreCLR dnx, you might see a similar problem. Pay close attention to the target framework in the error message:

For running:

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

When you're trying to run, you should remember that mental mapping from clr to target framework defined in your project.json.

This also shows up in Visual Studio under the references node:

The nodes marked as yellow are unresolved.

These also show up in the error list:

Building

These errors also show up when building. When building from the command line, the output is very verbose and can be extremely useful when diagnosing problems:

> kpm build

Building ClassLibrary39 for DNX,Version=v4.5.1
  Using Project dependency ClassLibrary39 1.0.0
    Source: C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39srcClassLibrary39project.json

  Using Assembly dependency framework/mscorlib 4.0.0.0
    Source: C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1mscorlib.dll

  Using Assembly dependency framework/System 4.0.0.0
    Source: C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1System.dll

  Using Assembly dependency framework/System.Core 4.0.0.0
    Source: C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1System.Core.dll

  Using Assembly dependency framework/Microsoft.CSharp 4.0.0.0
    Source: C:Program Files (x86)Reference AssembliesMicrosoftFramework.NETFrameworkv4.5.1Microsoft.CSharp.dll


Building ClassLibrary39 for DNXCore,Version=v5.0
  Using Project dependency ClassLibrary39 1.0.0
    Source: C:UsersdavifowlDocumentsVisual Studio 14ProjectsClassLibrary39srcClassLibrary39project.json

  Using Package dependency System.Console 4.0.0-beta-22709
    Source: C:Usersdavifowl.dnxpackagesSystem.Console4.0.0-beta-22709
    File: libcontractSystem.Console.dll

  Using Package dependency System.IO 4.0.10-beta-22231
    Source: C:Usersdavifowl.dnxpackagesSystem.IO4.0.10-beta-22231
    File: libcontractSystem.IO.dll

  Using Package dependency System.Runtime 4.0.20-beta-22231
    Source: C:Usersdavifowl.dnxpackagesSystem.Runtime4.0.20-beta-22231
    File: libcontractSystem.Runtime.dll

  Using Package dependency System.Text.Encoding 4.0.10-beta-22231
    Source: C:Usersdavifowl.dnxpackagesSystem.Text.Encoding4.0.10-beta-22231
    File: libcontractSystem.Text.Encoding.dll

  Using Package dependency System.Threading.Tasks 4.0.10-beta-22231
    Source: C:Usersdavifowl.dnxpackagesSystem.Threading.Tasks4.0.10-beta-22231
    File: libcontractSystem.Threading.Tasks.dll

The output shows all of the assemblies passed into the compiler from packages and project references. When you start getting build failures, it's useful to look here to make sure that the package you are using actually works on that target platform.

Here's an example of a package that doesn't work on 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 version 3.0.0 does not have any assemblies that run on dnxcore50 (take a look at the unzipped package's lib folder). When we run kpm build:

Notice it says "using Package Microsoft.Owin.Host.SystemWeb" but there is not "File:". This could be the reason for a build failure.

Here ends my brain dump

这篇关于如何诊断 dnx 中缺少的依赖项(或其他加载程序故障)?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

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