web-dev-qa-db-ja.com

dnxで依存関係の欠落（または他のローダーの障害）を診断するにはどうすればよいですか？

Kestrelを使用して、DNXでASP.NET vNextの HelloWebサンプル の修正バージョンを実行しようとしています。私はこれが出血しているエッジで非常にであることを理解していますが、ASP.NETチームが少なくとも可能な限りシンプルなWebアプリを機能させ続けることを願っています:)

環境：

  • Linux（Ubuntu、ほとんど）
  • モノラル3.12.1
  • DNX 1.0.0-beta4-11257（11249も利用可能です）

Startup.csの「Webアプリ」コード：

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 Assembly source でMicrosoft.Framework.Runtime.Interfacesを見つけましたが、最近は変更されていないようです。例外が名前を、別のアセンブリ内の単なるインターフェイスではなく、それ自体がアセンブリ全体であるかのように表示する理由は明らかではありません。 私はこれを推測しています多分は アセンブリニュートラルインターフェース によるものですが、エラーからは明らかではありません。 （ [AssemblyNeutral]は死んでいるので、そうではない... ）

c#asp.net-corednx
130
Jon Skeet

良い質問。特定の問題については、解決された依存関係に不一致があるようです。このような事態が発生した場合、互換性のないdnxでアプリケーションを実行している可能性があります。私たちはまだ非常に大きな破壊的な変更を行っているので、タイプが見つからないメソッドが見つからない場合、betaXパッケージとbetaY dnxを実行する可能性があります。

さらに具体的には、 Assembly Neutral Interfaces はbeta4で削除されましたが、実行中のアプリケーションはまだそれらを使用しているようです。

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

ただし、一般的には、dnxを使用するときにこのような問題を診断する方法に関するガイドを作成するときが来たように感じます（既存の.NETとはかなり異なるため）。

project.jsonに入れた依存関係はトップレベルのみです。バージョンもalways minimumsです（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を取得します。空のバージョンを指定することはALWAYS悪いため、今後のビルドでは許可されません。

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

1.0.0-*-プレフィックスに一致する最高バージョンを提供します（ セマンティックバージョニングルール による）ORそのプレフィックスに一致するバージョンがない場合、通常の動作を使用して最低バージョンを取得します> =指定されたバージョン。

最新のビルドで復元を実行すると、project.lock.jsonというファイルが書き込まれます。このファイルには、project.jsonで定義されているすべてのターゲットフレームワークの依存関係が推移的に閉じられます。

このようなことが失敗した場合、次のことができます。

kpm listを使用して、解決された依存関係を見てください。これにより、プロジェクトによって参照されるパッケージの解決されたバージョンと、それをプルした依存関係が表示されます。 A-> Bの場合、次のように表示されます。

 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

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

作業中のビジュアルスタジオ（現在DNXで中断している）がある場合は、参照ノードを見ることができます。視覚的に表される同じデータがあります：

References node

依存関係の失敗がどのように見えるか見てみましょう：

これが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を実行すると次のように表示されます。

enter image description here

復元が失敗した可能性があるときに診断する場合は、行われたHTTPリクエストを確認し、kpmがどの設定済みパッケージソースを調べたかを通知します。上記の画像では、CACHEリクエストがあります。これは、リソースのタイプ（nupkgまたはnuspec）に基づいた組み込みキャッシュであり、構成可能なTTL（kpm restore --helpを参照）があります。 kpmにリモートNuGetソースをヒットさせる場合は、--no-cacheフラグを使用します。

KPM restore --no-cache

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

enter image description here

サイドノート！

パッケージソース

NuGet.configの現在の動作について説明します（将来的に変更される可能性があります）。デフォルトでは、%appdata%\NuGet\NuGet.Configでグローバルに構成されたデフォルトのNuGet.orgソースを持つNuGet.configがあります。これらのグローバルソースは、Visual Studio内またはNuGetコマンドラインツールで管理できます。障害を診断するときは、常に有効なソース（kpm出力にリストされているソース）を確認する必要があります。

NuGet.configの詳細を読む here

現実に戻れ：

依存関係が解決されていない場合、アプリケーションを実行すると次のようになります。

> 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にも表示されます。 Unresolved dependencies

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

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

Error list unresolved dependencies

建物

これらのエラーは、ビルド時にも表示されます。コマンドラインからビルドする場合、出力は非常に詳細であり、問​​題を診断するときに非常に役立ちます。

> 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を実行すると：

Missing assemblies on dnxcore50

「パッケージMicrosoft.Owin.Host.SystemWebを使用」と書かれていますが、「ファイル：」はありません。これがビルドの失敗の原因である可能性があります。

ここで私の脳のダンプを終了します

144
davidfowl

完全に何が間違っていたのかはまだわかりませんが、少なくとも試してみるのを簡単にするための一連の手順があります：

  • 疑わしい場合は、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として指定されたときにバージョン1.0.0-beta4-11185をインストールしましたが、最後に-*を含むバージョン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": {}
  }
}
17
Jon Skeet

DNX_TRACEという名前のenv変数を1に設定すると、TONの詳細な診断情報を表示できます。注意してください、それはたくさん詳細です！

8
Eilon

それを機能させるために、私は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 . webまたはdnx . 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の後に）修正したようです。

3
Stephen Pope

最近、私のpackage.jsonバージョンはすべて"-rc2-*"で終わります

（これまで見てきた例外はMicrosoft.Framework.Configurationパッケージのみで、"1.0.0-rc1-*"または"1.0.0-*"のいずれかである必要があります）

@davidfowlが言及している「バージョントレイン」に関しては、beta8とrc2の間で多くの痛みが消えたようです。

dnvm upgrade -u -Arch x64 -r coreclr

これら2つのNuGetフィードを使用して、coreclrで最も幸運に恵まれました。

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

私がdoでパッケージの問題がない場合、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": {}
}
}
2
CrazyPyro

Dnxcore50およびdnx451の参照をなだめようとすると、依存関係が見つからないという問題もありました。

この正しい「依存関係」を理解すると、{}はフレームワーク間で共有されます。

次に、「フレームワーク」内の「依存関係」：{}：そのフレームワークに固有です。

dnxcore50はモジュラーランタイム（自己完結型）であるため、他の場所にコアの依存関係が散在している従来の.netフレームワークとは異なり、プログラムを実行するために必要なすべてのコアランタイムが基本的に含まれています。

それで、ある時点でMacまたはLinuxでホストすることにしたので、最小限のアプローチに固執したいと言いました。

更新 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"
  ]
}
1
C0r3yh