Como posso diagnosticar dependências ausentes (ou outras falhas do carregador) no dnx?


133

Estou tentando executar uma versão modificada do exemplo HelloWeb para o ASP.NET vNext no DNX usando o Kestrel. Entendo que isso está muito no limite, mas espero que a equipe do ASP.NET mantenha pelo menos o aplicativo Web mais simples possível funcionando :)

Meio Ambiente:

  • Linux (Ubuntu, basicamente)
  • Mono 3.12.1
  • DNX 1.0.0-beta4-11257 (também tenho 11249 disponíveis)

Código "aplicativo da Web", em Startup.cs:

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

Configuração do projeto, em 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 parece funcionar bem.

Quando tento executar, no entanto, recebo uma exceção sugerindo que Microsoft.Framework.Runtime.IApplicationEnvironmentnão pode ser encontrada. Linha de comando e erro (um pouco reformatado)

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

Embora, obviamente, minha necessidade mais urgente seja corrigir isso, também gostaria de receber conselhos sobre como avançar para diagnosticar o que está acontecendo de errado, para que eu possa resolver problemas semelhantes no futuro. (Isso também provavelmente tornará essa pergunta mais útil para outras pessoas.)

Encontrei Microsoft.Framework.Runtime.IApplicationEnvironmentna Microsoft.Framework.Runtime.Interfacesfonte do assembly e isso não parece ter mudado recentemente. Não está claro por que a exceção mostra o nome como se fosse um assembly inteiro, em vez de apenas uma interface dentro de outro assembly. Eu acho que isso pode ser devido a interfaces neutras de montagem , mas não está claro com o erro. ( [AssemblyNeutral]está morto, então não é isso ... )


por curiosidade, você quis fazer o link para github.com/aspnet/Home/wiki/Assembly-Neutral-Interfaces para o link de interfaces neutras do assembly ou em outro lugar? Como está atualmente quebrado
cgijbels

@cgijbels: Obrigado - eu realmente significou para link para davidfowl.com/assembly-neutral-interfaces mas sua ligação provavelmente melhor ...
Jon Skeet

As interfaces neutras da montagem @JonSkeet agora se foram.
tugberk

@tugberk: Puxa, sério? Isso é interessante - você tem um link que eu poderia incluir em uma edição?
Jon Skeet

Respostas:


144

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:

Nó de referências

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:

insira a descrição da imagem aqui

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:

Restauração do KPM - sem cache

Esses erros também aparecem no Visual Studio na janela de saída do log do gerenciador de pacotes:

insira a descrição da imagem aqui

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: Dependências não resolvidas

Os nós marcados como amarelos não foram resolvidos.

Eles também aparecem na lista de erros:

Lista de erros de dependências não resolvidas

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:

Assemblies ausentes no dnxcore50

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


Estou tentando usar a lista dnu como você sugere, para determinar por que o dnx não pode resolver uma dependência. Mas estou recebendo um vermelho "Não foi possível localizar o project.json". A montagem está na pasta de artefatos, gerada marcando "Produzir saídas na construção". Alguma sugestão de como proceder?
Mike Scott

O que a pasta de artefatos tem a ver com alguma coisa? Você fez referência à dependência em project.json? Esse pacote que você está referenciando está disponível em um feed configurado?
Davidfowl

17

Ainda não sei completamente o que estava errado, mas agora tenho uma série de etapas para pelo menos facilitar as tentativas:

  • Em caso de dúvida, reinstale o dnx
    • Explodir o cache do pacote pode ser útil
  • Verifique ~/.config/NuGet.configse você está usando os feeds NuGet certos

Acabei usando a seguinte linha de comando para testar várias opções de uma maneira razoavelmente limpa:

rm -rf ~/.dnx/packages && rm -rf ~/.dnx/runtimes && dnvm upgrade && kpm restore && dnx . kestrel

Parece que meu problema foi realmente devido às versões erradas das dependências que estão sendo instaladas. "1.0.0-beta4"Aparentemente, um número de versão de é bastante diferente "1.0.0-beta4-*". Por exemplo, a Kestreldependência instalou a versão 1.0.0-beta4-11185 quando apenas especificada como 1.0.0-beta4, mas a versão 1.0.0-beta4-11262 com o -*no final. Eu queria especificar beta4explicitamente para evitar usar acidentalmente uma versão beta3 com o

A seguinte configuração do projeto funciona bem:

{
  "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
Isso ocorre porque -*sempre fornece a versão mais recente do pré-lançamento, enquanto sem ela você obtém a versão mais baixa que satisfaz todas as dependências (como é habitual no NuGet). Este teste tem alguns exemplos.
Alexander Köplinger 12/03/2015

2
@ AlexanderKöplinger: Obrigado, isso faz sentido. Então ... beta4 é o beta4 mais antigo, enquanto ... beta4- * é o beta4 mais recente, certo?
Jon Skeet

4
"frameworks": {"dnx451": {}}tinha consertado para mim, não há necessidade dednxcore50
vicentedealencar 10/06/2015

Seu primeiro comando também me ajudou a deixar de ser preso na versão beta5. Eu tentei correr dnvm upgrade-self, isso não seria atualizado para a versão mais recente. A execução do prompt de comando do VS como administrador mostrou a versão do dnvm como rc1..., no entanto, quando não era como o administrador, era beta5.... Após o seu comando, os prompts de comando admin e non admin apareceram como a rc2...versão (mais recente).
precisa

Para aqueles que usam mono e se perguntam se deseja escolher dnx451ou dnxcore50esta resposta me ajudou a entender um pouco mais esse tópico: stackoverflow.com/a/30846048/89590 Resposta curta: dnx451é apropriado para mono.
Nate Cook

8

Você pode definir uma var env chamado DNX_TRACEpara 1ver um TON informações mais diagnóstico. Esteja avisado, é muito mais informação!


@JonSkeet BTW, as outras respostas (incluindo a sua resposta automática) contêm ótimas informações sobre como diagnosticar e reparar o problema específico que você encontrou. Eu mantive essa resposta super breve, porque é apenas outra resposta diferente que pode levar a mais pistas sobre o motivo do problema ter ocorrido.
Eilon

Absolutamente - eu aprecio isso :)
Jon Skeet

3

Para fazê-lo funcionar, modifiquei o meu project.json.. agora se parece com:

{
"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": {
    }
}

A chave parecia ser a seção de estruturas.

Também a renomeação mudou como k webfunciona, de modo que agora dnx . weboudnx . kestrel

Atualização - pouco mais informações

Estranhamente, depois de rodar sem estruturas definidas, ele ganhou um monte de coisas extras quando eu fiz 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

.. então correu bem. Então eu mudei de volta na seção de estrutura

"frameworks": {
    "dnx451": {}
}

.. e ainda funcionou, enquanto antes isso geraria um erro!

Muito estranho!

(Estou correndo 1.0.0-beta4-11257 )

Atualização adicional

Virei-se uma nova instância Ubuntu, e tenho o mesmo erro como você .. Meu pensamento foi que o problema pode ser causado por apenas tentando obter pacotes a partir nuget.orge não myget.org(que tem as coisas mais recentes) para que eu caiu em um NuGet.Configno raiz do projeto ..

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

.. isso parece ter corrigido isso para mim, obtendo as versões corretas (depois da outra kpm restore).


1
Re parte "dnx. Kestrel" - na verdade, daí o comando que mostrei :) Com essa configuração, recebo um erro diferente: System.TypeLoadException: Não foi possível carregar o tipo 'Microsoft.Framework.DependencyInjection.LoggingServiceCollectionExtensions' from assembly 'Microsoft. Framework.Logging, Versão = 1.0.0.0, Cultura = neutra, PublicKeyToken = null '. Qual versão do DNX você está usando?
Jon Skeet

1
Quando eu fiz o "dnx. Web" na primeira vez que obtive: `System.InvalidOperationException: falha ao resolver as seguintes dependências da estrutura de destino 'DNX, Versão = v4.5.1' e sugeriu uma lista dos itens que estavam faltando.
Stephen Pope

Interessante. Em que plataforma está, btw?
Jon Skeet

Você fez 'source ~ / .bashrc' para recarregar as variáveis ​​de ambiente depois de atualizar o DNX? Também eu tinha que fazer "upgrade de dnvm" + "uso dnvm default"
Stephen Pope

O DNX não havia sido atualizado pelo .bashrc ... possivelmente porque eu o construí manualmente ontem. Vai tentar usar as instruções atualizadas vez ...
Jon Skeet

2

Hoje em dia, todas as minhas package.jsonversões terminam em"-rc2-*"

(Apenas as exceções que vi até agora são os Microsoft.Framework.Configurationpacotes, que precisam ser um "1.0.0-rc1-*"ou"1.0.0-*" )

Com relação aos "trens de versão" mencionados por @davidfowl, parece que muita dor desapareceu entre beta8 e rc2.

dnvm upgrade -u -arch x64 -r coreclr

Eu tive mais sorte coreclrcom esses 2 feeds NuGet:

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

Quando eu faço tem falta de problemas de pacotes, 90% do tempo é esses mesmos culpados:

Newtonsoft.Json
Ix-Async
Remotion.Linq

Na maioria das vezes, eu posso contornar isso forçando o feed principal do NuGet.org:

dnu restore;
dnu restore -s https://nuget.org/api/v2

Aqui está o meu config.json de trabalho:

{
"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": {}
}
}

A lista acima não é de config.json, mas sim de project.json, mas eu ainda votei porque a lista me forneceu dependências úteis que eu não conhecia anteriormente.
Ron C

1

Eu também estava tendo problemas com problemas de dependência ao tentar apaziguar as referências dnxcore50 e dnx451.

Se eu entendo essas "dependências" corretas: {} são compartilhadas entre as estruturas.

Em seguida, "dependências": {} dentro das "estruturas": são específicas para essa estrutura.

O dnxcore50 é um tempo de execução modular (independente), portanto contém basicamente todos os tempos de execução principais necessários para executar um programa diferente da estrutura clássica .net, na qual você tem dependências principais espalhadas por outros lugares.

Então, com isso dito, eu queria seguir a abordagem mínima, caso eu decidisse hospedar no mac ou linux em algum momento.

Atualizar Ocorreu um problema estranho de dependência com as exibições cshtml, apenas foi fornecido com o dnx451 por enquanto.

Este é o meu 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"
  ]
}
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.