[解決済み] dnxで依存性の欠如（または他のローダーの障害）を診断するにはどうすればよいですか？

質問

の修正版を実行しようとしています。 HelloWeb サンプル を修正したものを、Kestrel を使用して DNX 上の ASP.NET vNext 用に実行しようとしています。私は、これが 非常に しかし、ASP.NET チームには、少なくとも最も単純な Web アプリケーションを動作させ続けることを期待します。）

環境です。

• Linux (Ubuntu、かなり)
• Mono 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.IApplicationEnvironment の中に Microsoft.Framework.Runtime.Interfaces アセンブリソース であり、それは最近変更されたようには見えません。なぜ例外が、他のアセンブリの中の単なるインターフェイスではなく、それ自体が全体のアセンブリであるかのように名前を表示するのかは不明です。


かもしれません によるもので アセンブリ中立インターフェース に起因するものですが、エラーからは明らかではありません。 ( [AssemblyNeutral] が死んでるからそれはないだろ...。 )

どのように解決するのですか？

良い質問です。あなたの特定の問題については、解決された依存関係の不一致があるように見えます。このようなことが起こる場合、おそらく互換性のない DNX でアプリケーションを実行していることが原因です。私たちはまだ非常に大きなブレークスルーを行っているので、もしメソッドが見つからないとか型が見つからないということがあれば、おそらくは最終的に betaX パッケージと betaY dnx、またはその逆となります。

さらに具体的には アセンブリニュートラルインターフェイス はベータ 4 で削除されましたが、実行しているアプリケーションはまだそれらを使用しているように見えます。

私たちは、パッケージがエラーメッセージをより明確にするために、実行に必要な最小限の dnx をマークできるようにする計画を持っています。また、時間が経つにつれて、破壊的な変更は減少するでしょう。

しかし一般的には、dnx を使用するときにこのような問題を診断する方法についてのガイドを書くべき時期だと感じています (既存の .NET とはかなり異なるため)。

に入れた依存関係 project.json はトップレベルのみです。また、バージョンは 常に最小値 (となります（NuGetパッケージのようなものです）。これは、指定したときに Foo 1.0.0-beta4 と指定した場合、実際には Foo >= 1.0.0-beta4 . つまり、もしあなたが MVC 0.0.1 で、設定されているフィードの最小バージョンは MVC 3.0.0 であれば、そちらを取得することになります。また NEVER は、あなたが指定しない限り、あなたのバージョンを浮動させることはありません。もし、1.0.0 を要求し、それが存在するならば、より新しいバージョンが存在しても 1.0.0 を入手することになります。空のバージョンを指定することは 常に であり、今後のビルドでは禁止される予定です。

私たちがnugetに導入している新しい機能で、フローティングバージョンと呼ばれるものがあります。今日は prerelease タグでのみ動作しますが、次のバージョンでは、バージョンのより多くの部分で動作するようになります。これは、パッケージ仕様ファイルでバージョン範囲を指定するための npm および gem 構文に似ています。

1.0.0-* - は、プレフィックスにマッチする最も高いバージョンを与えることを意味します。 セマンティックバージョニングルール ) または、そのプレフィックスに一致するバージョンがない場合は、通常の動作で、最も低いバージョン >=指定されたバージョンを取得します。

最新のビルドでリストアを実行すると、リストアは project.lock.json . このファイルには、以下のように定義されたすべてのターゲット フレームワークの依存関係の推移的クロージャが含まれます。 project.json .

このように失敗したときは、次のようにすればよいでしょう。

解決された依存関係を見てみましょう。 kpm list . これは、あなたのプロジェクトで参照されているパッケージの解決されたバージョンと、どの依存関係がそれを引っ張ってきたかを表示します。

A
  -> B
B
 ->

実際に出力されたKPMリスト。

Listing dependencies for ClassLibrary (C:\UsersdavifowlDocumentsVisual Studio 14Projects³³ClassLibrary39³³srcClassLibrary39project.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

* は直接依存を意味します。

もし、動作するビジュアルスタジオ（現在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 フラグを使用します。

これらのエラーは Visual Studio でもパッケージマネージャーのログ出力ウィンドウに表示されます。

横文字！？

パッケージのソース

今現在のNuGet.configの動作方法について説明します（将来的には変更される可能性が高いです）。デフォルトでは、デフォルトのNuGet.orgソースをグローバルに設定したNuGet.configを %appdata%\NuGet\NuGet.Config . これらのグローバルソースは、ビジュアルスタジオ内、または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 を実行するよう提案した場合、リストされた依存関係を見つけることができないからです。

このエラーが発生するもう 1 つの理由は、間違った dnx のフレーバーを実行している場合です。アプリケーションが dnx451 しか指定していないのに、CoreCLR dnx を実行しようとすると、同じような問題が発生する可能性があります。エラーメッセージのターゲット フレームワークに細心の注意を払ってください。

実行する場合。

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

実行しようとするとき、clrからターゲットフレームワークへのメンタルマッピングは、あなたの project.json .

これはVisual Studioでもreferencesノードの下に表示されます。

黄色でマークされたノードは未解決です。

これらは、エラーリストにも表示されます。

建物

これらのエラーはビルドするときにも表示されます。コマンドラインからビルドする場合、出力は非常に冗長であり、問題を診断する際に非常に有用となりえます。

> 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 :

<イグ

using Package Microsoft.Owin.Host.SystemWeb" と書かれていますが、 "File:" がないことに注意してください。これがビルド失敗の原因である可能性があります。

ここで私のブレインダンプを終了します。