dnx에서 누락 된 종속성 (또는 다른 로더 오류)을 어떻게 진단 할 수 있습니까?


133

Kestrel을 사용하여 DNX에서 ASP.NET vNext 용 HelloWeb 샘플 의 수정 된 버전을 실행하려고합니다 . 나는이 것을 이해 매우 출혈 가장자리에 많은,하지만 난 ASP.NET 팀은 적어도 가장 간단한 웹 응용 프로그램의 작동을 유지 것이라는 점을 희망 :)

환경:

  • 리눅스 (우분투, 거의)
  • 모노 3.12.1
  • DNX 1.0.0-beta4-11257 (사용 가능한 11249도 있음)

"웹 앱"코드 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]


호기심에서 어셈블리 중립적 인 인터페이스 링크 또는 다른 곳 에서 github.com/aspnet/Home/wiki/Assembly-Neutral-Interfaces 에 링크 하시겠습니까?
cgijbels

@cgijbels : 감사합니다.-실제로 davidfowl.com/assembly-neutral-interfaces 에 링크 하려고 했지만 귀하의 링크가 더 나을 것입니다 ...
Jon Skeet

@JonSkeet 어셈블리 중립 인터페이스가 이제 사라졌습니다.
tugberk

@ tugberk : 그래요? 흥미 롭습니다. 편집에 포함시킬 수있는 링크가 있습니까?
Jon Skeet

답변:


144

좋은 질문. 특정 문제의 경우 해결 된 종속성이 일치하지 않는 것 같습니다. 이와 같은 일이 발생하면 호환되지 않는 dnx에서 응용 프로그램을 실행하고 있기 때문일 수 있습니다. 우리는 여전히 큰 변화를 계속하고 있기 때문에 누락 된 유형의 메소드 누락이 발견되면 betaX패키지 를 실행 하고 betaYdnx를 또는 그 반대로 실행할 가능성이 있습니다 .

더 구체적으로, Assembly Neutral Interfaces 는 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에 새로운 기능이 도입되었습니다. 현재는 시험판 태그에서만 작동하지만 다음 버전에서는 더 많은 부분에서 작동합니다. 이것은 패키지 사양 파일에서 버전 범위를 지정하는 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로 깨짐) 참조 노드를 볼 수 있습니다. 시각적으로 동일한 데이터가 표시됩니다.

참조 노드

의존성 실패가 어떻게 생겼는지 살펴 보자.

프로젝트는 다음과 같습니다.

{
    "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.org 소스가있는 NuGet.config가 전역으로 구성되어 %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에 누락 된 어셈블리

"Package Microsoft.Owin.Host.SystemWeb 사용 중"이라고 표시되어 있지만 "파일 :"은 없습니다. 이것이 빌드 실패의 원인 일 수 있습니다.

여기 내 뇌 덤프가 끝났어


dnx가 종속성을 해결할 수없는 이유를 결정하기 위해 제안한대로 dnu 목록을 사용하려고합니다. 그러나 "project.json을 찾을 수 없습니다"라는 빨간색이 표시됩니다. 어셈블리는 아티팩트 폴더에 있으며 "빌드시 출력 생성"을 확인하여 생성됩니다. 진행하는 방법에 대한 제안?
Mike Scott

이슈 폴더는 무엇과 관련이 있습니까? project.json의 종속성을 참조 했습니까? 참조중인 패키지가 구성된 피드에서 사용 가능합니까?
davidfowl

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에서와 같이 모든 종속성을 만족시키는 가장 낮은 버전을 얻을 수 있기 때문 입니다. 이 테스트 에는 몇 가지 예가 있습니다.
Alexander Köplinger

2
@ AlexanderKöplinger : 감사합니다. 그렇다면 ... 베타 4는 가장 빠른 베타 4이고 ... 베타 4는 최신 베타 4입니다.
Jon Skeet

4
"frameworks": {"dnx451": {}}나를 위해 고정했다가 필요 없다dnxcore50
vicentedealencar

첫 번째 명령은 또한 beta5 버전에서 과거를 막는 데 도움이되었습니다. 을 실행하려고 시도했지만 dnvm upgrade-self최신 버전으로 업그레이드하지 않았습니다. admin으로 VS 명령 프롬프트를 실행하면 dnvm version이으로 표시 rc1...되었지만 admin이 아닌 경우였습니다 beta5.... 명령 후 admin 및 non admin 명령 프롬프트가 모두 rc2...(최신) 버전으로 표시되었습니다.
JabberwockyDecompiler

모노를 선택할지 궁금 사용하는 사람들을 위해 dnx451또는 dnxcore50이 대답을 나에게 조금 더이 주제 이해하는 데 도움 stackoverflow.com/a/30846048/89590 짧은 답변 : dnx451모노에 적합합니다.
Nate Cook

8

당신은라는 ENV var에 설정할 수 DNX_TRACE1토니 더 진단 정보를 볼합니다. 주의 할, 그건 많이 더 정보가!


@JonSkeet BTW 다른 답변 (자체 답변 포함)에는 발생한 특정 문제의 진단 및 복구에 대한 유용한 정보가 포함되어 있습니다. 나는 왜이 문제가 처음에 발생했는지에 대한 더 많은 단서를 이끌어 낼 수있는 또 다른 대답이기 때문에이 대답을 간단하게 설명했습니다.
Eilon

-감사합니다 :)
Jon Skeet

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

추가 업데이트

나는 새로운 우분투 인스턴스를 회전, 당신은 .. 내 생각이 문제가 단지에서 패키지를 얻으려고 노력으로 인해 발생할 수 있습니다 것을 같은 오류가 발생했습니다 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.Framework.DependencyInjection.LoggingServiceCollectionExtensions'형식을 어셈블리 'Microsoft에서로드 할 수 없습니다. Framework.Logging, 버전 = 1.0.0.0, Culture = neutral, PublicKeyToken = null '입니다. 어떤 버전의 DNX를 사용하고 있습니까?
Jon Skeet

1
"dnx. web"을 처음 받았을 때`System.InvalidOperationException : 대상 프레임 워크 'DNX, Version = v4.5.1'에 대한 다음 종속성을 해결하지 못했으며 누락 된 항목의 목록을 제안했습니다.
Stephen Pope

흥미 롭군 어떤 플랫폼입니까, btw?
Jon Skeet

DNX를 업그레이드 한 후 환경 변수를 다시로드하기 위해 'source ~ / .bashrc'를 수행 했습니까? 또한 "dnvm upgrade"+ "dnvm use default"
Stephen Pope

DNX는 .bashrc에 의해 업데이트되지 않았습니다. 어제 수동으로 구축했기 때문일 수 있습니다. 업데이트 된 지침을 대신 사용해보십시오.
Jon Skeet

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이 2 개의 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이 아니지만 이전에 알지 못했던 유용한 종속성을 제공했기 때문에 여전히 상향 조정되었습니다.
Ron C

1

dnxcore50 및 dnx451 참조를 완화하려고 할 때 종속성 누락 문제가 발생했습니다.

이 권한을 이해하면 "종속성": {}이 프레임 워크간에 공유됩니다.

그런 다음 "frameworks"내의 "dependencies": {}는 해당 프레임 워크에 고유합니다.

dnxcore50은 모듈 식 런타임 (자체 포함)이므로 기본적으로 다른 곳에 흩어져있는 핵심 종속성이있는 클래식 .net 프레임 워크와 달리 프로그램을 실행하는 데 필요한 모든 핵심 런타임이 포함되어 있습니다.

그래서 나는 어느 시점에서 맥이나 리눅스에서 호스트하기로 결정했을 때 최소한의 접근 방식을 고수하고 싶다고 말했다.

업데이트 cshtml 뷰에서 이상한 종속성 문제가 발생했습니다. 지금은 dnx451과 함께 사용되었습니다.

이것은 내 프로젝트입니다.

{
"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"
  ]
}
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.