Boa pergunta. Para o seu problema específico, parece que você tem uma incompatibilidade nas dependências resolvidas. Quando coisas assim acontecem, é provável que você esteja executando seu aplicativo em um dnx incompatível. Ainda estamos fazendo grandes alterações, por isso, se você encontrar um método ausente do tipo ausente, é provável que tenha acabado executando betaXpacotes e betaYdnx ou vice-versa.
Ainda mais especificamente, as interfaces neutras de montagem foram removidas na versão beta4, mas parece que o aplicativo que você está executando ainda as está usando.
Planejamos fazê-lo para que os pacotes possam marcar o dnx mínimo necessário para executar para tornar a mensagem de erro mais clara. Além disso, com o passar do tempo, as mudanças de ruptura desaparecerão.
Em geral, porém, sinto que é hora de escrever um guia sobre como diagnosticar problemas como esse ao usar o dnx (já que é bem diferente do .NET existente).
As dependências nas quais você coloca project.jsonsão apenas de nível superior. As versões também são sempre mínimas (é como um pacote NuGet). Isso significa que, quando você especifica, Foo 1.0.0-beta4está realmente especificando Foo >= 1.0.0-beta4. Isso significa que, se você solicitar MVC 0.0.1e as versões mínimas no seu feed configurado MVC 3.0.0, você receberá esse. Também NUNCA lançamos sua versão a menos que você a especifique. Se você solicitar a 1.0.0 e ela existir, você receberá a 1.0.0, mesmo que existam versões mais recentes. A especificação de versões vazias SEMPRE é ruim e não será permitida em versões posteriores.
Há um novo recurso que estamos apresentando ao nuget chamado versões flutuantes. Hoje funciona apenas na tag de pré-lançamento, mas na próxima versão funcionará em mais partes da versão. Isso é semelhante à sintaxe npm e gem para especificar intervalos de versão no arquivo de especificação do pacote.
1.0.0-*- Significa fornecer a versão MAIS ALTA que corresponde ao prefixo (de acordo com as regras de controle de versão semântica ) OU, se não houver uma versão correspondente a esse prefixo, use o comportamento normal e obtenha a versão MAIS BAIXA> = a versão especificada.
Ao executar a restauração nas versões mais recentes, ele gravará um arquivo chamado project.lock.json. Este arquivo terá o fechamento transitivo de dependências para todas as estruturas de destino definidas em project.json.
Quando algo assim falha, você pode fazer o seguinte:
Dê uma olhada nas dependências resolvidas usando kpm list. Isso mostrará as versões resolvidas dos pacotes referenciadas pelo seu projeto e qual dependência o atraiu. Por exemplo, se A -> B, mostrará:
UMA
-> B
B
->
Saída real da lista KPM:
Listando dependências para ClassLibrary39 (C: \ Usuários \ 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
* significa dependência direta.
Se você possui um visual studio em funcionamento (que rompe com o DNX agora), pode ver o nó de referências. Tem os mesmos dados representados visualmente:
Vejamos como é uma falha de dependência:
Aqui está o 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.0não existe. Portanto, a execução do kpm restore mostra o seguinte:
Ao diagnosticar quando a restauração pode ter falhado, observe as solicitações HTTP feitas, elas informam em qual fonte de pacote configurada o kpm foi acessado. Observe na imagem acima que há uma CACHEsolicitação. Esse é o cache embutido com base no tipo de recurso (nupkg ou nuspec) e possui um TTL configurável (veja kpm restore --help). Se você deseja forçar kpma acessar as fontes remotas do NuGet, use o --no-cachesinalizador:
Esses erros também aparecem no Visual Studio na janela de saída do log do gerenciador de pacotes:
Nota!
Fontes do pacote
Descreverei como o NuGet.config funciona agora (o que provavelmente mudará no futuro). Por padrão, você tem um NuGet.config com a fonte NuGet.org padrão configurada globalmente em %appdata%\NuGet\NuGet.Config. Você pode gerenciar essas fontes globais no visual studio ou com a ferramenta de linha de comando NuGet. Você deve sempre olhar para suas fontes eficazes (as listadas na saída em kpm) ao tentar diagnosticar falhas.
Leia mais sobre o NuGet.config aqui
De volta à realidade:
Quando as dependências não são resolvidas, a execução do aplicativo fornece o seguinte:
> 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)
O tempo de execução basicamente tenta validar que todo o gráfico de dependência foi resolvido antes de tentar executar. Se sugere executar kpm restore, é porque não consegue encontrar as dependências listadas.
Outra razão pela qual você pode receber esse erro é se estiver executando o sabor dnx errado. Se o seu aplicativo especificar apenas dnx451 e você tentar executar o CoreCLR dnx, poderá encontrar um problema semelhante. Preste muita atenção à estrutura de destino na mensagem de erro:
Para correr:
dnx4x - runs on dnx-clr-{etc}
dnxcore50 - runs on dnx-coreclr-{etc}
Ao tentar executar, lembre-se do mapeamento mental do clr para o framework de destino definido no seu project.json.
Isso também aparece no Visual Studio no nó de referências:
Os nós marcados como amarelos não foram resolvidos.
Eles também aparecem na lista de erros:
Construção
Esses erros também aparecem ao criar. Ao criar a partir da linha de comando, a saída é muito detalhada e pode ser extremamente útil ao diagnosticar problemas:
> 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
A saída mostra todos os assemblies passados para o compilador a partir de pacotes e referências de projeto. Quando você começa a obter falhas de construção, é útil procurar aqui para garantir que o pacote que você está usando realmente funcione nessa plataforma de destino.
Aqui está um exemplo de um pacote que não funciona no 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"
}
}
}
}
O Microsoft.Owin.Host.SystemWeb versão 3.0.0 não possui nenhum assembly que é executado no dnxcore50 (consulte a pasta lib do pacote descompactado). Quando corremos kpm build:
Observe que ele diz "usando o Pacote Microsoft.Owin.Host.SystemWeb", mas não há "Arquivo:". Esse pode ser o motivo de uma falha na compilação.
Aqui termina meu despejo cerebral