Runtime: Regras de segurança de herança violadas pelo tipo: 'System.Net.Http.WebRequestHandler'. Os tipos derivados devem corresponder à acessibilidade de segurança do tipo base ou ser menos acessíveis.

Acontece que olhei para isso hoje em outro relatório. / cc @ChadNedzlek

Parece que isso pode ser devido à falta de atributos de segurança no System.Net.Http.dll fora de banda em comparação com a caixa de entrada System.Net.Http.dll. A versão da caixa de entrada tem AllowPartiallyTrustedCallers. O mesmo acontece com a caixa de entrada System.Net.Http.WebRequest.dll. Isso significa que tudo é tratado como SecurityTransparent, a menos que seja anotado de outra forma.

O OOB System.Net.Http.dll está sem AllowPartiallyTrustedCallers, o que torna tudo crítico para a segurança. Agora, quando a caixa de entrada WebRequest.dll carrega o OOB System.Net.Http.dll, ela viola a regra de segurança, já que WebReqeuestHandler é transparente, mas HttpClientHandler do qual ele deriva é crítico.

Minha reprodução:

1. Arquivo> novo aplicativo de desktop
2. Propriedades do projeto> assinatura> habilitar assinatura de nome forte
3. Adicionar referência a System.Net.Http.WebRequest
4. Instale System.Net.Http 4.1.0.
5. No principal, basta chamar new WebRequestHandler ();

ericstj está certo, eu tenho o mesmo problema aqui. Este é um problema crítico no System.Net.Http 4.1.0 que deve ser reparado. Não posso usar esta biblioteca com .net4.6.1 porque falta consistência.

Esse problema é uma dor significativa de se lidar e, em particular, torna o uso do cliente Azure KeyVault penoso para minha equipe. A única alternativa indolor é fazer o downgrade para .NET 4.5.2, o que não é aceitável.

Além disso, a solução alternativa listada anteriormente é insuficiente. Se você quiser usar o NET 4.6.x, descobrimos que você deve fazer o seguinte para que funcione de forma confiável: desabilite a verificação de dependência, faça downgrade do System.Net.Http, edite o CSPROJ e desabilite o redirecionamento automático de vinculação, modifique o app.config e, normalmente, limpar / sair do VS / e reconstruir como sempre vi System.Net.Http em uso, mesmo para projetos triviais. Este é o procedimento que corrige isso de forma confiável.

1. Clique com o botão direito do mouse no projeto no Visual Studio e selecione Gerenciar Pacotes NuGet.
2. Vá para a guia Instalado.
3. Role para baixo até SYSTEM.Net.Http - não Microsoft.Net.Http.
4. No painel direito, se Instalado não for 4.0.0.0, defina a Versão como 4.0.0.0.
5. No painel direito, defina o comportamento da dependência para Ignorar dependências. Se você NÃO fizer isso, o pacote Microsoft.IdentityModel.Clients.ActiveDirectory sofrerá um downgrade substancial, o que NÃO está correto.
6. Clique em Atualizar - este botão deve realmente ser rotulado como "Alterar para versão".
7. Na janela de visualização, verifique se a ÚNICA alteração listada é "Instalando System.Net.Http". Se você se esqueceu de definir o comportamento de Dependência corretamente, a mudança adicional será listada aqui.
8. Clique em OK / Sim / Concordo nas caixas de diálogo de confirmação e aguarde a conclusão do processamento. Quando concluído, a lista de pacotes mostrará dois números de versão - a marca de seleção está ao lado daquele que está em uso.
9. Na guia NuGet instalado, selecione a lista para Microsoft.IdentityModel.Clients.ActiveDirectory.
10. No painel de detalhes à direita, defina o comportamento da Dependência como "Ignorar". Se você não fizer isso, qualquer adição subsequente do NuGet falhará quando a validação do NuGet para este pacote for executada.
11. No Visual Studio, selecione Arquivo | Salvar tudo.
12. Abra o arquivo CSPROJ para este projeto em um editor de texto.
13. Em / Project / PropertyGroup * 1 (o primeiro elemento PropertyGroup de Project), adicione a seguinte linha ou altere o valor deste elemento se ele já existir:
    <AutoGenerateBindingRedirects>false</AutoGenerateBindingRedirects>
14. Salve o arquivo e recarregue o projeto no Visual Studio.
15. Abra o arquivo app.config para este projeto.
16. Encontre a linha para System.Net.Http e edite-a para redirecioná-la para 4.0.0.0 em vez de 4.1.0.0. Então encontre isto:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.1.0.0" /> 
</dependentAssembly> 

E mude para isto:

<dependentAssembly> 
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
<bindingRedirect oldVersion="0.0.0.0-4.1.0.0" newVersion="4.0.0.0" /> 
</dependentAssembly> 

1. Reconstrua o projeto. Se você receber uma exceção ao executar o código do Azure Key Vault, um ou mais arquivos * .config nos diretórios bin / debug ou semelhantes não foram atualizados. Pode ser necessário sair do Visual Studio para limpá-los e reconstruí-los.

dluxfordhpf, obrigado pelo seu tempo explicando como você resolveu isso. Redirecionar para System.Net.Http 4.0 funcionou para mim em .net4.6.1, mas ainda é muito difícil de manter (a dependência do nuget). Olhando para a frente a versão que vai consertar isso.

O redirecionamento pode causar problemas se as pessoas estiverem usando qualquer uma das novas APIs adicionadas em System.Net.Http 4.1.0.

particularmente torna o uso do cliente Azure KeyVault doloroso para minha equipe

@ChadNedzlek teve o mesmo problema e foi capaz de contorná-lo passando um HttpClient que ele mesmo criou para o construtor KeyVaultClient. Se você não usar o WebRequestHandler, evitará o problema.

POR EXEMPLO:

c# var handler = new HttpClientHandler(); // configure handler // eg: handler.ServerCertificateCustomValidationCallback = (message, cert, chain, errors) => errors == SslPolicyErrors.None; var client = new HttpClient(handler); var kvclient = new KeyVaultClient(async (authority, resource, scope) => "foo", client);

@davidsh Acho que você precisa colocar AllowPartiallyTrustedCallers volta em System.Net.Http.dll. / cc @morganbr

@dluxfordhpf Muito obrigado pelas etapas.
É temporário e esperamos uma correção em breve, mas ainda assim, posso continuar a trabalhar no projeto!

@terrajobst Este é um problema de bloqueio de produção. Alguma ideia de quando podemos consertar o NuGet? Obrigado!

Apenas corri para isso sozinho. Seria incrível se não caíssemos no inferno da dependência em .Net. Ele está indo nessa direção.

EDIT: Corrigido com uma sugestão de comentários prévios para usar o sistema httpclient ??
new KeyVaultClient(GetAccessToken, new HttpClient(new HttpClientHandler()))
Isso pareceu entender ...

O problema só está piorando à medida que mais e mais pacotes nuget da Microsoft dependem da versão mais recente do System.Net.Http. Provavelmente não sou o único que atualiza constantemente seus pacotes nuget da Microsoft para a versão de pré-lançamento mais recente. Por exemplo, pacotes que não funcionam mais para mim em sua versão mais recente:

Microsoft.IdentityModel.Clients.ActiveDirectory
Microsoft.TeamFoundationServer.Client
Microsoft.VisualStudio.Services.Client.
....

Ainda não entendo por que este pacote ainda está disponível. @terrajobst @coolcsh podemos retirar / consertar este pacote? Está REALMENTE causando problemas com ambientes de aplicativos complexos. Várias horas desperdiçadas tentando evitar que o pacote ofensivo se infiltrasse na construção. Obrigado!

Estamos olhando para a vinculação ao System.Net.Http no NET Framework em vez dessa coisa quebrada do NuGet. Eu concordo, esse problema é ridículo e muito caro para lidar, pois você deve sincronizar as versões do NuGet entre os projetos, evitar atualizações de ligação automática e corrigir / verificar seu app.config. O que me surpreende é que esteja em uma montagem tão amplamente utilizada. Talvez a MS não se importe tanto com o KeyVault?

Também é usado pelo ActiveDirectory Nugget

Eu reverti algumas bibliotecas de direcionamento ao .NET Standard devido a isso e a problemas relacionados em que pacotes NuGet corrompidos apenas bagunçam os aplicativos voltados ao .NET Standard. Este é um lamentável estado de coisas.

Obrigado por preencher. Estamos investigando ativamente isso. Fique ligado.

Isso se tornou um problema significativo para mim; usamos muitos de nossos próprios pacotes nuget internamente. E parece que o nuget _não_ vai deixar aqueles bindingRedirect s sozinhos. Toda vez que atualizamos um de nossos pacotes internos, ele muda o redirecionamento de volta para newVersion="4.1.0.0" . Existe uma maneira de impedir que isso aconteça, ou existe uma correção no horizonte?

Encontrado ao executar o aplicativo em HTTPS, que funcionou bem em HTTP. Não tenho certeza se existem outras diferenças significativas.
A solução alternativa para definir newversion="4.0.0.0" funcionou para mim.

Ainda é um problema no NETStandard 1.6.1. Por quê?!

Lançado System.Net.Http 4.3.0. Alguém tentou?

@LoulG Sim, ainda é um problema, infelizmente.

Falei com @terrajobst no Twitter, e ele disse que na verdade é um problema maior, e eles têm

@LoulG mesmo aqui, atualizei todos os meus pacotes Nuget, com o lançamento do .net core 1.1 e tenho esse problema

System.TypeLoadException: Regras de segurança de herança violadas pelo tipo: 'System.Net.Http.WebRequestHandler'. Os tipos derivados devem corresponder à acessibilidade de segurança do tipo base ou ser menos acessíveis.

Em primeiro lugar, acho que foi devido a IdentityServer / IdentityServer3.AccessTokenValidation, mas, ao ler este problema, entendi minha situação t_t, passei várias horas tentando resolvê-lo

EDITAR:
AMD,
A solução alternativa para definir newversion = "4.0.0.0" funcionou para mim também

Tento atualizar para 4.3, mas o mesmo problema: (((

mesmo problema aqui após a atualização

Problema ainda presente com 4.3.0.

@terrajobst você pode fornecer atualizações sobre este problema ou qualquer outra visão sobre o problema mais profundo que @robertmclaws fez referência?

Alguma razão para essa correção funcionar localmente, mas quando implantada em um Serviço de Nuvem do Azure, o erro persiste?

Às vezes, empacotar o Azure pode atrapalhar seus redirecionamentos de ligação, tente descompactar o cspkg e ver o que realmente está sendo implantado.

Aqui está a versão do System.Net.Http.dll

Estou trabalhando nisso há alguns dias. Fiquei muito feliz por encontrar essa correção e chorando ao implantar no Azure.

E o arquivo .config contendo redirecionamentos de ligação para o projeto? Na verdade, espero que ele ainda implante a versão quebrada do assembly devido ao CopyLocal ser verdadeiro no pacote nuget, mas o redirecionamento de vinculação deve garantir que a versão da estrutura do assembly seja carregada dentro da VM do serviço em nuvem.

Isto é!!! WTH?

<dependentAssembly> <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> </dependentAssembly>

Olhando para trás em meu projeto, o web.config também foi revertido. Terei que retomar isso pela manhã. Obrigado por algumas pistas!

Eu acho que se você usar AutoGenerateBindingRedirects e, em seguida, modificar qualquer pacote nuget para o projeto, ele "corrigirá" seus redirecionamentos modificados manualmente de volta para a versão quebrada. Muito frustrante.

Mas parte do problema é que, se você NÃO usar AutoGenerateBindingRedirects ao adicionar novos pacotes, poderá ter outros problemas também.

Tenho lidado com esse absurdo há mais de uma semana, enquanto tenho que implantar uma nova versão do nosso aplicativo. O melhor que posso sugerir é adquirir o hábito de verificar seu web.config toda vez que você implantar.

Sim, você deve desabilitar as atualizações de vinculação por meio de edição manual no CSPROJ e, em seguida, corrigir os redirecionamentos de vinculação .config E reconfigurar o NuGet na GUI para NÃO atualizar as dependências e ENTÃO está tudo bem. Sim, este é um grande PITA, estou surpreso que esteja em produção há tanto tempo. Minha equipe tem xingado isso regularmente há meses.

Infelizmente, seguir o acima ainda corrige meu ambiente de desenvolvimento e não o prod azul. Eu verifiquei o arquivo pub mais recente e o web.config foi configurado corretamente junto com minha dll que está publicada sendo a versão mostrada acima. Infelizmente, meus problemas estão relacionados à biblioteca do Azure Search, portanto, essa correção estava se mostrando promissora. Alguma outra ideia por aí? Com um pouco de perda. Obrigado pela ajuda.

Por que isso tem mais de 2 meses? Isso é uma grande adversidade. Por favor conserte.

Este é um problema totalmente irrevogável, que precisa ser resolvido.

Pelo amor de f # $ @ pessoal, consertem isso já. Isso é idiotice.

@suprduprmn Eu atualizei e consolidei todos os pacotes e depois alterei isso em todos os arquivos app.config e web.config:

<bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.0.0.0" />

Só então meu aplicativo Web seria iniciado no Azure e seria capaz de fazer chamadas https para serviços do Azure que dependem de System.Net.Http. YMMV mas boa sorte.

E @terrajobst ... há um lugar apropriado para reclamar formalmente por negligenciar questões importantes como essa? As regras despreocupadas do código aberto não se aplicam aqui. Isso é coisa do Microsoft Showstopper 101 por volta de 1995. Não há como "a comunidade" ajudar. Você tem que consertá-lo e arquitetar ferramentas e processos para garantir que pare de acontecer. Estou vendo coisas assim em vários projetos da Microsoft e é totalmente inaceitável. É óbvio que existem enormes lacunas nos testes. Os cenários básicos simplesmente não são instalados ou compilados de forma limpa, muito menos funcionam corretamente em tempo de execução.

Quero me desculpar pelo tempo XXXL que demoramos para responder a este problema. Já se passou 1 mês desde a última resposta e o problema está aberto há mais de 3 meses. Concordo que isso não é aceitável para um problema de alto impacto como este.

Foi trazido à minha atenção esta manhã e eu tentei fazer algumas escavações históricas nas últimas horas. A boa notícia é que as pessoas certas estão investigando o problema nas últimas semanas (talvez até mais, não verifiquei todo o histórico). Infelizmente, a solução é muito complicada :( e é por isso que ainda não temos uma boa resposta ou ETA (embora não seja uma desculpa para a falta de atualização da nossa parte).
Existem algumas soluções possíveis, mas mesmo os especialistas ainda não estão de acordo e há desvantagens em cada uma delas.
Iniciaremos sincronizações diárias sobre o problema na próxima semana, tentando obter a solução para o problema o mais rápido possível. Vou postar atualizações (espero que com mais detalhes técnicos) quando as tivermos, pelo menos semanalmente.

Infelizmente, isso é o melhor que posso fazer neste momento (ou seja, sinceras desculpas e garantia de que estamos e vamos tratar isso com seriedade e faremos o nosso melhor para corrigi-lo o mais rápido possível). Se alguém tiver sugestões alternativas, sou todo ouvidos.

@karelz Não quero distrair a equipe de consertar o problema agora, mas pessoalmente adoraria ouvir uma análise post-mortem sobre a causa raiz desse problema e como ele passou pelo controle de qualidade. Isso tem causado grandes dores de cabeça e acho que a transparência ganharia alguma confiança.

@jahmai Entendido, também estou interessado nisso, mas quero me concentrar na solução primeiro. Então, podemos analisar o que aconteceu, por que e como evitar tais contratempos no futuro.

Obrigado pela resposta. Acho que a melhor solução no momento é desativar qualquer pacote que não aponte para System.Net.Http 4.0.0. Existem pelo menos 2 versões do pacote que são ruins. Não é esse o objetivo de distribuir essas coisas através do NuGet em primeiro lugar?

abraços @ ms-team

Além disso, só para você saber, entre este problema, os problemas em torno do HttpClient sendo tão mal projetado, os problemas em torno de Microsoft.Security.Owin.Jwt sendo quebrados nas dependências atuais e o estado do .NET Core ...

É um momento extremamente frustrante para ser um desenvolvedor .NET agora. Cada implantação agora requer 30 minutos de verificação de referências de associação de montagem para que meus aplicativos não sejam interrompidos na produção. Esta não é a Microsoft que defendo há tanto tempo. Eu amo vocês, e não quero ser rude ... Mas parece que um amor duro é necessário para restaurar o status quo de qualidade.

O que tiver que ser feito. Mesmo que isso signifique enviar um 4.3.1 que faz referência ao antigo pacote 4.0. Por favor, faça logo.

Obrigado rapazes. FWIW, se você precisar fazer uma alteração significativa, faça-o. Não gostamos disso, mas estamos convivendo com a dor há vários meses e, agora que sabemos que você está envolvido, podemos esperar mais alguns, mesmo que tenhamos que fazer algumas alterações na API.

Algo está fora dos trilhos aqui. Há 15 anos que envio aplicativos C #. Ironicamente, como abstrações de nível mais alto estão sendo distribuídas pela Microsoft, estou gastando cada vez mais tempo cavando profundamente em detalhes internos com os quais nunca tive que me preocupar. VOCÊ ESTÁ FAZENDO ISSO ERRADO.

Não sou inteligente o suficiente para entender por que reverter os sinalizadores de confiança nesta biblioteca é um grande negócio, nem entendo por que não tenho mais controle sobre isso em meu aplicativo de qualquer maneira.

Se eu quisesse ser surpreendido no tempo de execução por erros induzidos por biblioteca aleatória e gerenciamento de pacotes que o compilador não detectou, escreveria meus aplicativos em Ruby.

Rápida atualização:
Nós nos encontramos várias vezes esta semana. Discutimos as opções e descobrimos o financiamento.
@CIPop está trabalhando nesta questão como prioridade (o trabalho foi transferido de @davidsh, que estará

Status:

• Conseguimos reproduzir a reprodução original de @onovotny e criar uma pequena reprodução.
• Estamos buscando a solução [3] abaixo - focalizando sua questão em aberto, ou seja, validando a viabilidade técnica da opção.
• Estamos explorando a solução paralela [2] abaixo - examinando sua questão aberta, ou seja, avaliando o impacto da solução no ecossistema.

Descrição do Problema

• Enviamos System.Net.Http 4.3.0.0 “OOB” em junho
  
  
  
  • Conteúdo notável (para este contexto): HttpCient, HttpClientHandler
  
  
  • Valor para o cliente: Suporte a certificados, suporte a http2, pilha WinHttp na área de trabalho
  
  
  • Todas as plataformas, exceto Desktop, funcionam bem - para Desktop, a superfície da API não tem SecurityAttributes para o código PartialTrust (APTCA = AllowPartialTrustCodeAttribute)
  
  
  • No Desktop, a biblioteca OOB substitui o uso de System.Net.Http 4.0.0.0 que faz parte da plataforma (e tem APTCA)
  
  
• System.Net.WebRequestHandler 4.0.0.0 faz parte do Desktop
  
  
  
  • Depende de System.Net.Http e tem APTCA, portanto, requer System.Net.Http para ter APTCA
  
  
  • Ele usa tipos internos de System.Net.Http (que possui InternalsVisibleTo)
  
  
  • É o tipo legado “enfadonho” que não queremos no .NET Core
  
  
• Existem bibliotecas (3+ pacotes NuGet e aplicativo ASP.NET Core na área de trabalho) que trarão (indiretamente) tanto OOB System.Net.Http 4.3.0.0 quanto a referência a System.Net.WebRequestHandler 4.0.0.0. A combinação impede que o aplicativo seja executado.

Soluções

1. [NÃO ACEITÁVEL] Redirecionamento de vinculação manual - manualmente por downgrade de aplicativo (por meio de redirecionamentos de vinculação) System.Net.Http 4.3.0.0 a 4.0.0.0 - é difícil entender o que / onde e é uma etapa manual por aplicativo
   
   
   
   • Observação: usado hoje como “a solução alternativa”
   
   
2. [CANDIDATO] Desfazer decisão OOB - reenviar 4.3.1.0 como redirecionar para a caixa de entrada Desktop 4.0.0.0.
   
   
   
   • Desvantagem: vamos quebrar os clientes que dependem das novas funcionalidades
   
   
   • Pergunta aberta: o WCF ou outras bibliotecas NuGet no Desktop serão afetadas?
   
   
3. [CANDIDATE] Atributos de segurança espalhados em System.Net.Http
   
   
   
   • Faça isso apenas para o Desktop (use #if), não propague para outros pacotes (compile com a referência do Desktop), adicione testes para aplicá-lo no futuro.
   
   
   • Desvantagem: algumas propriedades WebRequestHandler específicas para a implementação do Desktop de System.Net.Http não funcionarão (por design, conforme mudamos a implementação)
   
   
   • Nota técnica: Os métodos assíncronos devem ser SecurityTransparent (limitação do compilador Roslyn), portanto, eles não podem chamar (SecurityCritical) PInvokes - para cada chamada PInvoke, deve haver um método wrapper SecuritySafeCritical (meio feio, mas direto)
   
   
   • Pergunta aberta: podemos fazer as dependências internas do WebRequestHandler funcionarem com o novo System.Net.Http baseado em WinHttp?
   
   
4. [REJEITADO] OOB WebRequestHandler apenas no desktop
   
   
   
   • Desvantagem: Empurra o problema para cima (alguns conjuntos APTCA dependem disso)
   
   
   • Desvantagem: Algumas propriedades WebRequestHandler específicas para a implementação do Desktop de System.Net.Http não funcionarão (por design) - veja [3] acima
   
   
   • Desvantagem: todos têm que adicionar a dependência ou dizer ao NuGet para instalar o mais recente
   
   
5. [CANDIDATE] Empacote System.Net.WebRequestHandler.dll no pacote System.Net.Http NuGet
   
   
   
   • 2 desvantagens iguais a [4] acima:
     
     
     
     
     
     1. Desvantagem: Empurra o problema para cima (alguns conjuntos APTCA dependem disso)
     
     
     
     2. Desvantagem: Algumas propriedades WebRequestHandler específicas para a implementação do Desktop de System.Net.Http não funcionarão (por design) - veja [3] acima
     
     
     
   
   

Obrigado pelas informações detalhadas, nós apreciamos isso.

Que tal uma combinação da Opção 2 e reenvio 4.3 como 5.0? Como foi tecnicamente uma alteração significativa, você também pode enviar um OOB WebRequestHandler.dll para desktop como v5.0. Isso permitiria que você reimplementasse a funcionalidade em WinHttp, tornasse obsoleto propriedades que não mapeiam e proporcionaria a todos uma maneira de avançar da maneira que o SemVer deveria permitir. O upstream ainda precisaria corrigir seu código também, mas isso não é inesperado em uma versão principal, e eles também poderiam apenas fazer o limite superior de seus pacotes para não incluir o 5.0.

Quer dizer, eu tive a ideia de querer enviar todos os grupos de pacotes do framework com os mesmos números de versão, mas a) aquele cão já estava ferrado quando vocês enviaram tudo como 4.0 em vez de seguir o controle de versão do Desktop existente, eb) o verdadeiro o controle de versão do assembly já está em todo lugar (o pacote System.Security.Claims 4.3 vem com 4.0.2 dll, o que é muito irritante quando se tem que construir redirecionamentos de ligação). Portanto, o dano já está feito.

dotnet / corefx # 3 parece ser a única solução de causa raiz real para mim.

@robertmclaws Não achamos que a mudança de versão faria diferença. A maioria das pessoas (proprietários de aplicativos e bibliotecas) normalmente apenas "clica em atualizar para o mais recente" em seus pacotes, eles não se importam com o quanto a versão mudou (menor vs. maior). Portanto, o impacto de ruptura será exatamente o mesmo.
É ainda pior que o efeito de "quebra" apareça apenas quando você combinar várias coisas. É por isso que esse problema passou despercebido em primeiro lugar - não temos testes para esse combo (e eu diria que está tudo bem - não se pode testar todas as combinações, mas podemos discutir isso no post-mortem mais tarde).

Eu não acho que ninguém se preocupa muito com versões de grupos de framework inteiros também. Honestamente, se eu acreditasse que ajudaria a maioria dos clientes, eu votaria apenas pela alteração dos números - só não acredito que ajudaria em quase nada. Isso apenas mudaria nossa mensagem para "sim, você está quebrado - é o que a versão diz, você simplesmente não percebeu com que tipo de coisas você concorda quando pega a versão", o que é uma desculpa esfarrapada da IMO.

Dada a diferença de opiniões, estou interessado no que os outros pensam: por favor, use votos positivos / negativos nesta postagem:

• 👍 se você concordar comigo, ou seja, você acha que enviar as alterações importantes como 5.0 não fará diferença e a maioria das pessoas ainda estará quebrada, confusa e impactada.
• 👎 se você concordar com a proposta de @robertmclaws , ou seja, você acha que enviar a alteração importante como 5.0 ajudará as pessoas a entenderem de antemão que elas devem ficar longe do pacote, porque isso quebrará a combinação com outra biblioteca e evitará problemas desnecessários para os desenvolvedores.

Para criar versões de mudanças significativas, acho que 5.0 é uma boa ideia, mas não me sinto muito nisso.

Ainda estou muito confuso sobre o que está causando esse problema no primeiro
Lugar, colocar. Vocês estão realmente falando sobre a minha cabeça.

Eu me importo muito com os números de versão correspondentes, mas se isso tiver
ir para acabar com esse problema, eu cuido disso.

Não li um artigo há alguns meses sobre como a maioria dos
A biblioteca System.Net.Http estava sendo desativada em favor de uma reconstruída?

Em 15 de dezembro de 2016, 15h18, "Karel Zikmund" [email protected] escreveu:

@robertmclaws https://github.com/robertmclaws Não achamos que o
a mudança de versão faria a diferença. A maioria das pessoas (aplicativo e biblioteca
proprietários) normalmente apenas "atualizar para o mais recente" em seus pacotes, eles
não importa o quanto a versão mudou (menor vs. maior). Então a quebra
o impacto será exatamente o mesmo.
É ainda pior que o efeito de "quebra" só virá à tona quando
você combina várias coisas. É por isso que esse problema escapou no
primeiro lugar - não temos testes para esse combo (e eu diria
tudo bem - não se pode testar todas as combinações, mas podemos discutir isso em
post-mortem mais tarde).

Eu não acho que ninguém se preocupa muito com versões de grupos de framework inteiros
ou. Honestamente, se eu acreditasse que ajudaria a maioria dos clientes, eu
votaria apenas em alterar os números - só não acredito que iria
quase ajuda em tudo. Isso apenas mudaria nossa mensagem para "sim, você é
quebrado - é o que diz a versão, você simplesmente não percebeu que tipo de
coisas com as quais você concorda ao fazer a versão ", o que é uma desculpa esfarrapada da IMO.

Dada a diferença de opiniões, estou interessado no que os outros pensam:
por favor, use votos positivos / negativos neste post:

• 👍 se você concorda comigo, ou seja, você acha que enviar o troco de última hora
  já que 5.0 não fará diferença e a maioria das pessoas ainda estará quebrada,
  confuso e impactado.
• 👎 se você concorda com @robertmclaws https://github.com/robertmclaws 's
  proposta, ou seja, você acha que enviar a alteração decisiva como 5.0 ajudará
  as pessoas entendem desde o início que devem preferir ficar longe do pacote,
  porque vai quebrar a combinação com outra biblioteca e evitar
  dor desnecessária para os desenvolvedores.

-
Você está recebendo isso porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267446604 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAavtBRE24SlHsZHCYm5OhPbOGs6MfRzks5rIa68gaJpZM4JsdDX
.

Eu concordo. Peguei alguns detalhes do e-mail de hoje, mas ainda não tenho certeza. Seria bom ver uma boa descrição do problema interno para que possamos entender as soluções propostas.

@karelz Agradeço o que você está tentando fazer aqui, mas fazer uma votação sobre o que significa "versão 5.0" é uma perda de tempo total. É a socialização do GitHub, não a engenharia. Eu lançaria uma versão 5.0 HOJE que corrige isso e uma 6.0 quando você descobrir como definir todas as suas pequenas anotações corretamente e / ou refatorar o código.

Declarações como "A maioria das pessoas (proprietários de aplicativos e bibliotecas) normalmente simplesmente atualiza para a versão mais recente" não são úteis. É assim que Perl 6, Python 3, Rails 3 & 4 e Node.js 1,2,3,4,5 & 6 conseguiram fragmentar as coisas. Não vamos seguir essa pista.

@dluxfordhpf @ciel Infelizmente, esta é uma área difícil de explicar. Tudo está vindo de um código de segurança "legado" que não é mais recomendado para uso.

Aqui está um resumo de qual é / era seu propósito:
https://msdn.microsoft.com/en-us/library/ee191569 (v = vs.110) .aspx
https://msdn.microsoft.com/en-us/library/dd233102 (v = vs.110) .aspx

O problema real tem a ver como @karelz disse com um tipo de um nível de transparência de segurança (por estar na estrutura do desktop) tentando derivar de um tipo que tem uma postura de segurança menos restritiva (porque os atributos estão faltando no Versão OOB). Isso ocorre porque o CAS, como conceito, não existe em nada além de .net desktop.

No contexto dos documentos acima, veja esta seção sobre Regras de herança

Ele descreve as regras necessárias para a herança de tipos em diferentes níveis de segurança.

Obrigado! Estou familiarizado com o CAS; técnicos são maravilhosos.

Considerando todas as alterações de número de versão entre .NET Core, .NET Standard, et. al. no ano passado (e enviando um novo código com a versão 4.3 em NuGet que roda em 4.6.2, eu entendo que a Microsoft pode não achar que os números de versão importam. Mas como alguém que gerencia sozinho uma arquitetura de aplicativo muito complexa e distribui mais de 20 NuGet OSS pacotes, eu discordo de todo o coração.

Clicar em "Atualizar tudo" sem verificar a compatibilidade é a maneira mais fácil no .NET de bagunçar seu aplicativo e não saber até o tempo de execução. A adesão ao SemVer é a única maneira de manter qualquer senso de sanidade. Incrementar a versão principal comunica que algo será quebrado. Ao sinalizar essa mudança, você terá a liberdade de fazer o que quiser para consertá-la.

A correção proposta parece boa para mim, mas eu gostaria apenas de comentar sobre a matriz de teste - o uso de HttpClient no desktop .NET será uma coisa importante em um futuro próximo. Esta combinação realmente deve ser testada, embora seja verdade que nem todas as possibilidades podem / devam ser testadas.

Sim, o teste soa como uma desculpa para mim também. Adicione os 100 melhores pacotes ao seu projeto de teste de unidade e certifique-se de que sua porcaria ainda funcione. Parece o tipo de engenharia básica que a Microsoft costumava fazer antes de perceber que poderia despedir os testadores e deixar "a comunidade" resolver o problema. É uma perda de tempo terrível e frustrante.

Porque o 'antigo' controle de qualidade que nos trouxe o Windows ME e o Vista eram superiores.

Além disso, tenho certeza de que insultá-los fará o trabalho mais rápido.

Em 16 de dezembro de 2016, 7h46, "chadwackerman" [email protected] escreveu:

Sim, o teste soa como uma desculpa para mim também. Adicione os 100 melhores
pacotes para seu projeto de teste de unidade e certifique-se de que sua porcaria ainda funcione.
Parece o tipo de engenharia básica que a Microsoft costumava fazer antes
percebendo que eles poderiam despedir os testadores e deixar "a comunidade" classificar isso
em vez disso. É uma perda de tempo terrível e frustrante.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267597137 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAavtAUL3pmMiSRnFBe7DEa0y5AaZoVXks5rIpZIgaJpZM4JsdDX
.

Encontrou o líder da equipe que ninguém convida para as festas de fim de ano porque ele
trata as pessoas como merda.

Em 16 de dezembro de 2016, 8:26 AM, "chadwackerman" [email protected] escreveu:

Gritar besteira, acredite ou não, faz o trabalho mais rápido.
Caso contrário, você tem gerentes de desenvolvimento milionários que não escreveram uma linha de
código em 10 anos dizendo "Uau, essa coisa do Github com certeza é legal. vamos hackear o
votar positivamente / votar negativamente emoji e realizar uma votação para que eu não tenha que tomar uma decisão. "
Como se isso fosse resolver qualquer coisa depois de meses de trabalho e seis
horas de reuniões de triagem internamente. É uma falsa sinalização social e
francamente, o tipo de engenheiros de BS costumavam chamar que nos trouxe qualidade
como o foguete Saturn V. E .NET, que foi o melhor pacote de linguagem
e biblioteca padrão de qualquer coisa neste espaço muito antes de tudo isso online
idiotice começou.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267604666 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAavtEigDK5EqlA4LQVlxB_lfamMgHanks5rIp9-gaJpZM4JsdDX
.

Ou talvez você tenha encontrado o cara que aprendeu a desbloquear toda a sua equipe fazendo a Microsoft finalmente agir em um problema que foi ignorado por meses.

A Microsoft tem listas de bugs e prioridades completamente duplicadas internamente. Github é um monte de bobagens sociais. Eles não aceitariam uma solicitação pull para esse problema de qualquer maneira, então isso se transforma em um tópico de suporte ao cliente. Os desenvolvedores fizeram um péssimo trabalho aqui e não há problema em ouvirem.

Há uma grande diferença entre os desenvolvedores ouvirem isso e serem um
idiota insuportável. Se comentários insultuosos são a única maneira de transmitir uma
ponto, então talvez você deva se limitar a repreender as pessoas com quem você está
pagando para te aturar.

Em 16 de dezembro de 2016, 8h34, "chadwackerman" [email protected] escreveu:

Ou talvez você tenha encontrado o cara que aprendeu a desbloquear toda a sua equipe
fazer a Microsoft finalmente agir em um problema que foi ignorado por meses.

A Microsoft tem listas de bugs e prioridades completamente duplicadas internamente.
Github é um monte de bobagens sociais. Eles não aceitariam um pedido de pull para
este problema de qualquer maneira, então isso se transforma em um tópico de suporte ao cliente. Os devs
fez um péssimo trabalho aqui e eles podem ouvir isso.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/dotnet/corefx/issues/11100#issuecomment-267606461 ,
ou silenciar o tópico
https://github.com/notifications/unsubscribe-auth/AAavtHTdxym7pvR9KRomyIT14FVaILLFks5rIqF8gaJpZM4JsdDX
.

Vou responder apenas porque a Microsoft usa "classificar por GitHub número_de_comentários" para ajudar no que @karelz tão educadamente vazou como "descobrir financiamento". Você pode usar a escala de emoji do GitHub para validar seus valores sociais também.

O cara entrou e disse que o SemVer não importa. É nosso dever como engenheiros apontar o quão absurdo isso é. É um caso clássico em que precisamos de um gerente mais sênior que tenha experiência real, ou de um cara mais jovem que realmente saiba como as coisas afetam o mundo real. Gerentes de nível médio jogando como prefeito no GitHub são o verdadeiro problema aqui. Agora, fique à vontade para clicar no polegar para baixo para que possamos todos continuar com o nosso dia, obrigado.

Sim, esse bug foi uma droga, e estou surpreso ao ver um caminho principal sev1 lançado. Mas, IMHO, a verdadeira dor disso se deve ao design do NuGet: qualquer pacote NuGet usado por um projeto deve ser referenciado manualmente por todos os consumidores desse projeto. Isso é duplicação desnecessária e design ruim, que o leva ao fracasso. O assistente de sincronização é inútil quando o projeto básico é ruim. NUGET é por isso que esse bug é tão doloroso. Do contrário, fumaríamos, colocaríamos a solução alternativa desagradável em Util e seríamos capazes de esquecê-la. Mas agora temos que ter cuidado em todos os 18 ou mais projetos que consomem, crescendo a cada mês. É por isso que esse bug é tão doloroso - por causa do NuGet, a correção não pode ser isolada para um projeto, você tem que tocar em tudo e continuar fazendo isso.

Além disso, concordo com a opinião de que Desktop / Windows .NET é o que importa. Estou feliz em saber que o Microsoft .NET está chegando ao Linux, mas o dinheiro está no Windows, é onde devemos ter a melhor experiência, e quero que ele execute da melhor forma.

Uma reclamação contínua que minha equipe tem é "por que temos que baixar todos esses pacotes?" Criamos um console ou projeto ASP.NET e tudo de que ele precisa está na caixa. Você cria algo mais moderno e 5 bilhões de downloads.

OK, estou ficando um pouco longe do campo. Obrigado pelo seu tempo e atenção e informe-nos se pudermos ajudá-lo a testar / avaliar / verificar se há erros de digitação nos documentos / tudo o que você precisar, estamos dispostos a ajudar.

A razão pela qual esse problema (e dotnet / runtime # 17786) causou tanta dor para nós é porque mudamos nossos serviços de nuvem de funções da web do Azure para serviços do Service Fabric e tivemos que mudar para netcore / netstandard, mas ainda executando em estrutura completa aplicativos.

No início, fiz a solução alternativa de redirecionamento de vinculação que parecia funcionar por um tempo, mas nossos desenvolvedores estavam constantemente quebrando algo ao reverter acidentalmente um app.config, atualizando um pacote nuget e lutando contra AutoGenerateBindingRedirects (cuja desativação era seu próprio pesadelo).

Por fim, resolvi isso forçando o uso de HttpClientHandler em todos os lugares. Isso envolveu alterar nosso próprio código, levantar problemas em bibliotecas de terceiros e até mesmo usar hacks como reflexão e duplicação de código de terceiros para contornar o problema.

Portanto, seja qual for a solução, se o novo pacote não suportar o HttpClient / HttpClientHandler mais recente, não o aceitaremos. Isso não é um grande problema, porque agora as coisas estão funcionando. No entanto, a "correção real" precisa vir logo depois, já que não quero ser bloqueado na atualização de ainda mais pacotes de terceiros que podem estar movendo seu código para o padrão de rede e apresentando este problema.

@dluxfordhpf ... Seria bom ver uma boa descrição do problema interno para que possamos entender as soluções propostas ...

Tentei descrever o problema aqui: https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198.
Resumindo:

• O pacote Http NuGet 4.1 / 4.3 "substitui" o Http 4.0 no .NET Framework, mas não tem atributos de segurança. Além disso, ele usa diferentes componentes do sistema operacional sob o capô (ou seja, "grande mudança" + potencialmente quebrando caixas de canto (embora não seja diretamente relevante para este problema, é um sinal de que há problemas)).
• WebRequestHandler é apenas parte do .NET Framework, mas depende do Http 4.0 e requer atributos de segurança no Http.
• Depois de assumir a dependência do Http 4.1 / 4.3 do NuGet e redirecionar a versão 4.0 .NET Framework da caixa de entrada para ele, você não poderá usar o WebRequestHandler.
• Para piorar as coisas, o Http tem algumas novas APIs que fazem parte do .NET Standard 1.6 e alguns componentes dependem delas. Portanto, não podemos simplesmente voltar para a versão anterior.
• E, claro, os detalhes tornam tudo ainda mais complicado.
• Afirmando o óbvio: Não existe uma "solução certa". É questão de escolher aquele que tem menos impacto geral.

@chadwackerman ... fazer uma votação sobre o que significa "versão 5.0" é uma perda de tempo total. É a socialização do GitHub, não a engenharia.

Não é socializar. Se você olhar os votos, mostra que não há opinião unânime sobre o assunto. Portanto, mesmo que você não confie na opinião da equipe CoreFX (com mais de 10 anos de experiência com clientes .NET) que diz "as pessoas não prestam atenção à versão principal como desejamos ", espero que ajude ver que até mesmo alguns MVPs ( @onovotny) compartilham dessa opinião. Enquanto outros MVPs discordam (@robertmclaws).

@chadwackerman ... Eu

É a opção [2] que defini acima (com números de versão diferentes). É algo que estamos explorando em paralelo. Dado o impacto da solução, não está claro " sim - essa é obviamente a coisa certa a fazer, vamos em frente ".

@robertmclaws ... A Microsoft pode não pensar que os números de versão importam ... Quando você sinaliza essa mudança, você obtém a liberdade de fazer o que quiser para corrigi-la ...

Não tentei dizer que não acreditamos nas versões certas. Nós apenas acreditamos que uma parte significativa dos desenvolvedores não se importa e quer que tudo seja totalmente compatível sempre - ou seja, não podemos fazer o que queremos, mesmo em grandes colisões de versão. Isso se baseia nos anos de experiência de nossa equipe em serviços .NET e envio de pacotes NuGet.

@gulbanana ... Esta combinação realmente deveria ser testada, embora seja verdade que nem todas as possibilidades podem / devem ser testadas ...

Concordo, agora que sabemos que é uma combinação importante, devemos adicionar cobertura para ela. E devemos examinar a área um pouco mais para ver se estamos perdendo outros combos semelhantes em torno do pacote Http NuGett.

@chadwackerman ... Adicione os 100 principais pacotes ao seu projeto de teste de unidade ...

Engraçado, isso é semelhante ao que propus um ano atrás, quando enviamos o Meta-pacote ruim para UWP devido à falta da cobertura de teste correta. Simplesmente não é tão fácil. Para detectar os bugs interessantes (como este), você também precisa exercitar o código. Freqüentemente, você precisa exercitar o código de ambos os combos no mesmo teste (não neste caso específico). No geral, é bastante difícil no teste infra.
Se você tiver sugestões e ideias que possamos ter perdido, informe-nos - vamos criar uma nova edição para esse tópico.

@chadwackerman ... e deixe "a comunidade" resolver essas coisas ...

Nós (posso falar pelas equipes CoreFX e CLR) NÃO estamos terceirizando o teste de produtos para a comunidade via GitHub. Mantemos um alto padrão de qualidade do que enviamos.

(tecla de atalho acidental enviou a resposta antes de eu terminar ... para continuar ...)

@chadwackerman ... A Microsoft duplica completamente listas de bugs e prioridades internamente ...

Isso não é verdade, pelo menos nas equipes CoreFX e CoreCLR - o GitHub é o banco de dados de bug primário para todo o .NET Core. Outros produtos de código-fonte não aberto (.NET Framework "completo" e .NET Native) usam principalmente bancos de dados de bug internos.

@chadwackerman ... Eles não aceitariam uma solicitação pull para esse problema de qualquer maneira ...

Não aceitaremos uma solicitação pull que não seja capaz de abordar / explicar todas as preocupações acima (incluindo aquelas com as quais a pessoa que a enviou não concorda pessoalmente). Existem projetos de código aberto que seriam hackeados rapidamente sem pensar em todo o seu impacto? Talvez se 20% + de seus clientes estão no chão ... não é o caso aqui (ainda).

@chadwackerman ... A Microsoft usa "classificar por GitHub number_of_comments" para ajudar no que @karelz tão educadamente vazou como "descobrir financiamento". ...

Em primeiro lugar, number_of_comments não é uma métrica à qual prestamos atenção (a menos que alguém "manualmente" perceba que ele sai do telhado). E definitivamente não tem nada a ver com "financiamento".
Prestamos atenção a qualquer coisa que tenha impacto sobre os clientes - seja o número de votos ou a insatisfação expressa do cliente (no GitHub, Twitter, comentários em postagens de blog, em qualquer outro lugar).
Esse bug entrou no meu radar como "insatisfação significativa do cliente" (outro funcionário da MS neste tópico o levantou como tal internamente), é por isso que entrei em cena.
Estamos financiando tanto quanto podemos neste momento. A única prioridade mais alta seria um problema de segurança ou 20% + dos nossos clientes estão no local sem uma solução alternativa.
BTW: Jogar insultos não vai ajudar a acelerar ou influenciar a tomada de decisão.

@dluxfordhpf ... por favor, deixe-me saber se podemos ajudá-lo a testar / avaliar / verificar documentos para erros de digitação / o que você precisar, estamos dispostos a ajudar ...

Obrigado, nós apreciamos sua oferta. Definitivamente, receberemos ajuda quando tivermos bits prontos (e validados nas repros que temos), para validar mais cenários ponta a ponta. Queremos evitar uma situação em que consertamos apenas alguns cenários de ponta a ponta, enquanto deixamos outros quebrados da mesma ou de outra maneira.

@jahmai ... mas nossos desenvolvedores estavam constantemente quebrando alguma coisa ao reverter acidentalmente um app.config, atualizando um pacote nuget e lutando contra AutoGenerateBindingRedirects (que desabilitá-lo era seu próprio pesadelo). ...

Obrigado! Esse é um bom exemplo para esclarecer o impacto do problema no trabalho diário do desenvolvedor que precisamos ouvir e entender. Isso nos ajuda a entender que a combinação com as ferramentas do VS torna isso um verdadeiro pesadelo de se trabalhar. Vamos levar isso em consideração ao finalizar o plano de lançamento e as datas (que começarei assim que definirmos a solução).

@jahmai ... se o novo pacote não suportar o HttpClient / HttpClientHandler mais recente, não o aceitaremos ...

Mais uma vez, bom feedback para ouvir. Ainda estamos tentando descobrir todas as correções de ponta a ponta e história de lançamento, antes de aceitarmos totalmente uma solução. Liberar um hack sem entender o impacto em outros cenários (como o seu) seria uma jogada desesperada de nossa parte - consideraríamos apenas, se não soubéssemos como consertá-lo, ou se a correção adequada fosse extremamente cara. Nós ainda não estamos lá.

Por favor, vamos manter a discussão técnica de agora em diante.

Rápida atualização:
A solução [3] " Atributos de segurança Sprinkle em System.Net.Http ", conforme descrito acima, parece ser cara (6w +), então dinamizamos seus detalhes de implementação interna: Estamos considerando usar a implementação Http original da versão 4.0 do pacote + implementar as 8 novas APIs em cima dele da melhor maneira possível (algumas podem estar tecnicamente quebrando com soluções alternativas). O suporte http2 e outras "novas pilhas WinHttp" não estarão disponíveis por padrão, quem quiser precisa chamar o construtor especial (tecnicamente quebrando a mudança, mas espero que muitas pessoas não dependam dos novos itens 4.1 / 4.3 ocultos) .
O custo parece ser significativamente menor até agora, mas ainda estamos perseguindo e custando 2 pontas perdidas (APIs), antes de definirmos o plano final. Teremos que tomar algumas decisões "interessantes" de compatibilidade pelo menos para 2 APIs, mas elas não devem retardar o tempo para o lançamento da correção.

BTW: A solução [2] " Desfazer decisão OOB " acabou tendo mais impacto do que imaginávamos originalmente (por exemplo, quebraria o padrão .NET 1.6, criando mais confusão e explicações de longo prazo). Estamos mantendo essa opção como último recurso neste momento, se o acima exposto for muito caro ou irracional.

se você está analisando os casos extremos em torno desse problema, pode valer a pena conferir:
https://github.com/gulbanana/repro-netstandard-httpclient

esta solução demonstra que atualmente em vs2017rc, usando netfx e netstandard resulta em versões conflitantes de system.net.http. não tenho certeza de como isso se relaciona com a coisa OOB.

Eu aprecio (e francamente admiro) @karelz candor aqui, mas vou tocar a trompa de versão uma última vez.

se você não confia na opinião da equipe CoreFX (com mais de 10 anos de experiência com clientes .NET) que diz "as pessoas não prestam atenção à versão principal" ... com base nos anos de experiência de nossa equipe com serviços .NET e envio de NuGet pacotes ...

Não tenho certeza de qual falácia lógica é essa, mas você não pode reivindicar uma compreensão profunda de uma equipe experiente e cheia de nuances de versionamento no meio de um enorme problema de versionamento como este.

Esperançosamente, podemos pelo menos concordar que NÃO ultrapassar o número da versão principal e ter uma alteração significativa é o pior de todos os mundos. No entanto, aqui estamos. Falando em "orçamento" e "6+ semanas de tempo de desenvolvimento" ... para acrescentar alguns atributos. Para um sistema de confiança desatualizado que nunca funcionou de verdade e que não uso. Por causa de problemas negligenciados no compilador.

A Amazon Web Services forneceu suporte completo do .NET Core para todos os seus serviços no verão passado. Sua atualização recente reduz a barra do padrão líquido de 1,5 para 1,3. Enquanto isso, a equipe do Azure nem consegue fazer os blobs funcionarem.

Vocês enviaram bits que quebram globalmente as solicitações da web https, silenciosamente durante as compilações e ruidosamente no tempo de execução, e ainda não têm um plano para resolvê-lo quatro meses depois. Vou deixar isso de lado por enquanto, porque obviamente você está trabalhando nisso - mas se os problemas maiores aqui não estão te mantendo acordado à noite ...

Muito obrigado pela sua franqueza e suas explicações.

@chadwackerman ... você não pode reivindicar uma compreensão profunda de uma equipe experiente de versionamento no meio de um problema massivo de versionamento como este. ... Com sorte, podemos pelo menos concordar que NÃO ultrapassar o número da versão principal e ter uma alteração significativa é o pior de todos os mundos. No entanto, aqui estamos. ...

Você está fazendo duas grandes suposições:

1. Suposição: a alteração significativa é conhecida (também conhecida como considerada falha) antes do envio.
   
   
   
   • Esse não é o caso para este problema - como é comum para a classe de "alterações de interrupção não intencionais". Sim, às vezes as coisas escapam :(. As métricas importantes são IMO: reação rápida (concordo que não fizemos isso direito sobre esse assunto até agora) e diminuição / baixa frequência de tais erros.
   
   
2. Suposição: Os especialistas em controle de versão são capazes de revisar cada mudança (o que não é) e que as pessoas em geral nunca cometem erros (ficção científica).
   
   
   
   • Nesse caso específico, o plano de API System.Net.Http (as novas 8 APIs para Desktop) foi revisado em alto nível antes do envio também por especialistas em versões. Eles forneceram sugestões e orientações sobre as opções. Infelizmente, o nível de quebra não foi reconhecido de antemão por ninguém (nem especialistas da área, nem especialistas em versionamento), portanto, a solução escolhida levou a esses problemas.
   
   

Também quero salientar que, ao descartar nossa experiência de versionamento, você está basicamente dizendo " se você (equipe .NET) alguma vez cometer um grande erro (esse bug), não tem permissão para se considerar um especialista, mesmo no histórico anterior e do cliente padrões (área relacionada) ".
Esse é o grande martelo da IMO e não é realista. Pessoas / equipes cometem erros ocasionais (como este). Isso não os torna inadequados para serem especialistas nas áreas próximas (ou mesmo na área específica). O importante é se eles podem aprender com seus erros e se sair melhor no futuro.

@chadwackerman ...

O custo não é de "atributos de tapa", essa é a parte fácil. A parte cara vem da questão aberta da opção [3]:

https://github.com/dotnet/corefx/issues/11100#issuecomment -267394198: Pergunta aberta: podemos fazer as dependências internas do WebRequestHandler funcionarem com o novo System.Net.Http baseado em WinHttp?

Acontece que isso dá muito trabalho, as dependências internas são muito desagradáveis ​​:(

Eu realmente aprecio toda a discussão sobre isso. A sério. É incrivel. Obrigado por estar aberto sobre isso.

No final do dia, porém, aqui está o problema do dotnet / corefx nº 1: vocês reescreveram a maior parte da pilha. A parte central de quase tudo. E você não tem cobertura de teste nem remotamente adequada. Não deveria ter precisado de especialistas. Ele deveria ter um caso de teste claramente documentado que foi escrito no momento em que WebRequestHandler foi escrito (ou a decisão foi tomada para não portar para o Core), e deveria ter quebrado quando vocês começaram a brincar com ele.

Depois de mais de 5 anos lançando coisas relacionadas ao .NET 4.0, realmente não há desculpa para não ter cobertura de teste de integração EM ALGUM LUGAR que isso teria ocorrido. Se você se pega dando uma desculpa, não está exigindo excelência de sua equipe.

Se tivesse havido:

• cobertura de teste adequada
• um processo de controle de qualidade adequado
• uma versão beta adequada
• e uma maneira adequada de enviar problemas para equipes específicas responsáveis ​​por pacotes específicos

... isso não teria acontecido.

Se a equipe:

• não tinha se empenhado tanto em ferver o oceano ao reescrever CADA ÚNICO ASPECTO do .NET ao mesmo tempo
• atendeu aos avisos daqueles de nós que têm falado sobre isso desde o início do projeto ".NET 5 / MVC 6"

... isso não teria acontecido.

É uma combinação de falhas que quebrou o .NET em grande escala, em uma escala que não me lembro de ter acontecido antes. Mas você também quebrou uma grande parte do ecossistema e está se tornando cada vez mais difícil de consertar.

Há um custo _muito real_ e _significante_ nisso. Tivemos que desligar nosso CI Server semanas atrás e implantar manualmente, verificando o web.config manualmente todas as vezes. Desdobramos pelo menos uma vez por dia. Centenas de dólares por semana em horas-homem adicionais, sem mencionar os atrasos de ter que gastar esse tempo fazendo outra coisa.

Novamente, isso nem mesmo leva em consideração as incontáveis ​​horas lidando com as falhas existentes na arquitetura HttpClient: isso não está descartando as instâncias adequadamente, mantendo as conexões TCP abertas e armazenando entradas DNS por muito tempo.

Então, você vai receber algumas críticas por isso. E merecidamente.

E com base no quão "caro" o conserto é, espero que você esteja colocando uma equipe de tigres de vários de seus melhores funcionários para consertar direito, e não colocando nos ombros de uma pessoa.

... As surras continuarão até que o moral melhore.

Deixe-os consertar o erro que admitiram e não se prender ao tato.

Só para deixarmos claro, não estou tentando bater em um cavalo morto com minha última postagem. Mas eu tenho visto muitas desculpas da Microsoft recentemente. "Nomear é difícil." "O controle de versão é difícil." "Pessoas cometem erros." Essa é a mentalidade de fraqueza, e não de uma equipe que busca a excelência. Eu realmente admiro @karelz por vir aqui e discutir isso. Mas qualquer funcionário da MSFT precisa parar de justificar o que aconteceu e permitir que as pessoas desabafem sem sentir a necessidade de perder tempo corrigindo o registro. Esta não é uma exceção de caso super-extremo quando você usa um DateTime ou algo assim. É um efeito colossal pelo fato de mais de uma pessoa não exigir excelência em seu trabalho, e deve ser tratada como tal. A única resposta válida é: "Nós erramos. Nós quebramos o .NET. Não vamos descansar até que seja consertado." Porque essa teria sido a resposta 5 anos atrás, quando Gu estava comandando o show.

Eu simpatizo com @karelz, que recentemente assumiu seu cargo após um longo tempo trabalhando em .NET. E ele certamente não deveria ter que defender seu time. Eu não culpo os trabalhadores aqui; é obviamente um problema de gerenciamento.

Mas talvez não deva ser um choque ver a lógica circular e o tipo de conversa dupla que é comum em certas camadas da administração da Microsoft não funcionarem bem na frente dos clientes do mundo real que realmente usam essas coisas.

No .NET Core, o Microsoft SQL Server perdeu a capacidade de gravar valores não assinados. Mais uma vez, um problema negligenciado que está no topo dos sites do UserVoice desde 2014. As empresas não têm o luxo de alterar seu esquema de banco de dados (especialmente algo tão complicado quanto não assinado) porque alguns gerentes de programa não conseguem entrar na mesma página depois de três anos. Enquanto isso, Redis e SQLite (seja lá o que for) funcionam bem, e Scott Hanselman arrasa com as demonstrações de feiras como se essas coisas realmente funcionassem. Definitivamente, há uma lacuna cada vez maior entre as realidades internas e externas aqui e as questões precisam ser (educadamente) ventiladas.

Nomear é difícil. O controle de versão é difícil. A Microsoft tem uma perspectiva única, na qual lida com clientes de todos os tipos de setores, desde a mais recente até a última geração. Conceitos de abordagem de desenvolvimento que parecem “óbvios” em jogos são estranhos em sistemas de CRM. A maneira como você aborda os problemas, o que é importante e o que não é importante, variam. E então você adiciona tecnologia avançada, abordagens diferentes para problemas: DAO vs ADO.NET vs LINQ vs EF para usar uma comparação fácil comum. Finalmente, a competição no domínio dos servidores de Internet, modelos de hardware totalmente novos com tablets prontos para uso e o vírus Balmer. Novas formas de pensar e modelar problemas com diferentes limitações e vantagens.

A certa altura, trabalhei para uma ... grande empresa famosa. Um grupo de produtos lançou um produto com um componente compartilhado atualizado que interpretou sua pilha de chamadas de maneira diferente, dependendo de como foi inicializado. Eles nunca o testaram com nosso produto, e isso fazia com que nosso produto explodisse todas as vezes. Óbvio, mas eles enviaram mesmo assim. Chamamos isso de incidente de “fogo amigo”.

Perdi um bug uma vez em que, se instalássemos na unidade D, ao desinstalar sob certas condições, o produto poderia ... excluir todos os arquivos do HD. Tivemos que queimar $ 40k de CDs prensados.

As pessoas não são perfeitas e cometemos erros. Culpar, no entanto, é um conceito inútil. Isso nos faz sentir poderosos por meio de conceitos destrutivos como vergonha e humilhação. A humildade e o perdão são mais poderosos. É assim que fazemos melhor, aprendemos maneiras melhores e, às vezes, simplesmente porque algo é importante em primeiro lugar.

Sim, o problema também me deixa com raiva, mas está sendo consertado. E você sabe o que mais - problemas de código aberto como esse definham por décadas antes mesmo de tentar. Apenas tente fazer o Kerberos em um sistema Linux ou procure no GSSAPI. InitializeSecurityContext / AcceptSecurityContext é MUITO mais fácil. Dinheiro importa.

A certa altura, trabalhei para uma ... grande empresa famosa. Um grupo de produtos lançou um produto com um componente compartilhado atualizado que interpretou sua pilha de chamadas de maneira diferente, dependendo de como foi inicializado. Eles nunca o testaram com nosso produto, e isso fazia com que nosso produto explodisse todas as vezes. Óbvio, mas eles enviaram mesmo assim. Chamamos isso de incidente de “fogo amigo”.

Esses eram dois produtos diferentes. .NET é um único produto. E não estou tentando culpar ninguém. Eu culpo o processo. Parece que, porque a Microsoft se tornou um software livre, eles jogaram os processos que os ajudaram a lançar a estrutura de desenvolvimento mais estável da história pela janela. Acho que isso teria sido detectado se tivesse sido fornecido no .NET 4.6.3 em vez do NuGet.

A transição desajeitada para o OSS certamente não está ajudando em nada. Eu não culpo o OSS, mas a Microsoft certamente parece estar orgulhosa de cometer todos os erros óbvios.

Uso palavras como "qualidade" para descrever software, mas agora usam palavras como "engajamento". Executar o compilador instrumentado que liga para casa mais vinte vezes por dia porque tenho que editar manualmente os arquivos .config não é um "envolvimento adicional". Mas esse é o mito de toda a internet atualmente.

Considere a equipe do BashOnWindows que decidiu ter um monte de pessoas sem experiência em Linux para escrever um shim de modo de usuário Linux ao vivo no GitHub. O trabalho é um exercício de engenharia básico, mas tedioso, e não há absolutamente nenhuma razão para envolver o feedback da comunidade para a priorização de recursos. Mas eles foram embora.

Seis meses depois, "a comunidade" teve que dizer a eles que não conseguia lidar com arquivos que terminavam em um período. Isso não é engenharia de software; é uma espécie de exercício de marketing estranho. Os gerentes que estão implícitos no esquema merecem feedback. E parte disso pode ser desagradável de ouvir.

Edite para adicionar: acordo semelhante com o desastre do Bash. Enviando pedaços quebrados ao vivo, ligações estranhas com outros componentes (só podiam ser instalados como parte do Windows Update) e, claro, Scott Hanselman de alguma forma fazendo demonstrações ao vivo, apesar do fato de que não podia rodar tar e muito menos um compilador.

Algumas das retóricas aqui remetem aos "bons velhos tempos" da Microsoft, o que é irônico porque todas as mudanças que estamos testemunhando agora são uma resposta direta à demanda dos clientes para que a Microsoft evolua.

Estávamos cansados ​​de regras de código fechado e engenharia reversa draconiana (descompilação), então temos fontes de referência e agora código aberto.

Estávamos cansados ​​dos bugs do .net Framework que afetavam todos os aplicativos instalados em uma máquina e levavam muito tempo para consertar e exigiam a distribuição corporativa e os departamentos de TI para qualificar cada atualização de versão do .net Framework antes que pudesse acontecer, então agora estamos indo em direção envio de pacotes nuget com nossos aplicativos para que possamos implementar a correção assim que estiver disponível.

Estávamos cansados ​​de o Microsoft Connect encerrar todos os outros bugs como "funcionando conforme projetado" ou levar 6 meses para até mesmo agendar um lançamento, então agora temos os projetos do Github gerenciados muito mais de perto pela equipe que realmente escreve o código e o todo a comunidade pode facilmente dar 2c em cada item de trabalho gerado pela comunidade.

Estávamos cansados ​​de a Microsoft pegar todas as boas ideias da comunidade e fazer um clone proprietário que não funcionava bem com ferramentas que não eram da Microsoft, então agora podemos usar NPM, Gulp, NodeJS, etc.

Estávamos cansados ​​de C # só ser viável para Windows, e projetos como o Mono lutando para se manter no mesmo nível, tendo que contornar bugs ou falta de funcionalidade com #ifdef em todos os lugares, então agora temos Xamarin impulsionando o desenvolvimento Mono com fontes de referência e nos permitindo para codificar a linguagem C # mais recente e compartilhar a mesma base de código em .net, UWP, iOS, Android e netcore.

Tudo isso está acontecendo ao mesmo tempo porque aconteceu. Não vamos esperar que a Microsoft se atualize enquanto ela fornece peças de funcionalidade estáveis ​​e perfeitas que resolvem apenas metade dos nossos problemas a qualquer momento.

Meu problema não é que toda essa mudança esteja acontecendo ao mesmo tempo. Nem que haja problemas como esse aparecendo. O verdadeiro problema para mim é que _ levou meses até que esse problema fosse reconhecido como um problema importante _ e está demorando _ ainda mais meses para descobrir como corrigi-lo _.

Três semanas e nenhuma atualização. Feliz Ano Novo a todos.

Edite para adicionar esta citação de @karelz, pois o eufemismo parece desencadear um grupo ligeiramente diferente de flocos de neve especiais aqui:

Vou postar atualizações (espero que com mais detalhes técnicos) quando as tivermos, pelo menos semanalmente.

@chadwackerman sério, você entende que sua atitude negativa não ajudará a resolver esse problema mais rapidamente? E fora isso, você está se fazendo de bobo aqui. Por favor, melhore seu tom.

Que tom? Ele fez uma declaração, que tem a vantagem de ser precisa, e então desejou a todos um Feliz Ano Novo. Se você aceitou negativamente, o problema é seu.

E com relação à primeira afirmação: este é um grande problema de quebra que não aparece até o tempo de execução. Cinco anos atrás, ScottGu ou Rob Howard teria uma equipe neste 24-7 até que uma solução fosse enviada. Agora é apenas "você sabe, nós vamos dar um jeito nisso".

Você sabe o que vai deixar as pessoas felizes? Corrigir o problema. Caso contrário, existem alguns clientes irritados por aí, e alguns deles estão neste tópico. Eles têm todo o direito de estar chateados. Portanto, encontre algo mais para fazer com sua indignação, @pollax. Você não contribuiu com nada significativo para este tópico e ninguém o ungiu como Polícia de Pensamento do GitHub. Você também não desperdiçou mais de $ 5K do dinheiro de sua empresa com esse problema.

Ok, talvez eu tenha lido muito sobre isso e por causa do tom que ele usou nos comentários anteriores, eu li este último com um tom um pouco irônico. Me desculpe por isso.
Em relação ao assunto; Eu te escuto. Estou preocupado com isso (caso contrário, não estaria observando este problema tão de perto), então, por favor, não faça suposições sobre o que desperdicei / não desperdicei em termos de dinheiro / recursos com isso. Mas, como desenvolvedor, sei que a pior coisa é ter alguém olhando para você ao tentar consertar um problema importante.

Concordo com sua leitura de sarcasmo e concordo, não é produtivo. Eu também concordo com a sensação de “quando isso será consertado”, no entanto. Infelizmente, esse problema CAT1 do caminho principal simplesmente não deu atenção até que muitas pessoas começaram a falar sobre isso. Espero que haja alguma melhoria de processo internamente para resolver isso; Seria péssimo para todos nós se a única maneira de conseguirmos consertos fosse por meio de palavrões.

Também estou recebendo um relatório sobre o que está acontecendo no framework completo com nosso pacote nuget Exceptionless. Alguma solução sólida ou solução alternativa?

Também consigo hospedar o ASP.NET Core de um serviço do Windows executando o framework completo 4.6.2. dependência NETStandard.Library 1.6.1 me força a usar System.Net.Http 4.3.0.

dependência NETStandard.Library 1.6.1 me força a usar System.Net.Http 4.3.0.

e este é o meu maior problema com toda esta situação

mais e mais pacotes estão dependendo do meta-pacote, forçando-me a atualizar todas as dependências que tenho (ou travar uma batalha difícil de rebaixar / ignorar as específicas)

isso vai contra a promessa anterior de "misturar e combinar" de dependências do sistema

Tive que fazer o downgrade do meu sistema para 4.5.2 de 4.6.1 (e perdendo um tempo significativo), porque cada segundo pacote trazia .net 1.6 e seu System.Net.Http com bugs

Se esses fossem apenas pacotes de terceiros, bem, que seja, eu posso contorná-los, importunar os mantenedores para usar dependências mais granulares, mas a maioria dos meus departamentos eram do MS, e espero que o MS use dependências granulares, não basta inserir .net 1.6 no arquivo nuget

Eu planejava enviar uma atualização dos últimos dias, então aqui está:

O trabalho de @CIPop foi prejudicado por um problema de segurança. Seu trabalho foi escolhido por @davidsh. @davidsh planeja enviar RP no início desta semana (ou seja, qualquer dia agora).

Aqui estão os detalhes sobre nosso plano de execução e status:

Plano de alto nível:
A. Substitua WinHttpHandler por HttpClientHandler na compilação net46 do CoreFX
B. Implementar 8 novas APIs em HttpClientHandler que introduzimos no pacote OOB 4.1.0.0

Plano de execução:

EDIT 2017/1/12 - o plano de execução foi movido para a postagem mais alta https://github.com/dotnet/corefx/issues/11100#issue -173058293

@niemyjski Alguma solução alternativa ?

Há uma solução alternativa para fazer o downgrade do pacote ofensivo para 4.0.0.0 (consulte https://github.com/dotnet/corefx/issues/11100#issuecomment-246469893), infelizmente, conforme os comentários acima, qualquer edição nas dependências do NuGet o trará de volta - que é a principal razão pela qual este problema é tão doloroso.

Espero que haja alguma melhoria de processo internamente para resolver isso; Seria péssimo para todos nós se a única maneira de conseguirmos consertos fosse por meio de palavrões.

Eu tenho algumas idéias (e perguntas) sobre as melhorias de processo aqui, para evitar que problemas de impacto importantes no futuro passem despercebidos por tanto tempo. No entanto, estou adiando intencionalmente essa discussão DEPOIS de enviarmos uma correção.

Woot !!!

Muito bem pessoal @karelz

Obrigado pela atualização. PlatformNotSupported seria melhor do que nada, já que são novas apis nas quais o software legado não depende.

Parece pós-correção, a unificação por meio de redirecionamentos de vinculação ainda será necessária, mas um redirecionamento para o assembly mais recente em vez de para o mais antigo, qual nuget pode gerar corretamente?

Agora que PR dotnet / corefx # 15036 foi verificado, esse problema deve desaparecer em net46. System.Net.Http.dll agora está usando a pilha HTTP interna do .NET Framework. Isso significa que ele tem 100% de compatibilidade com WebRequestHandler.

Experimente os pacotes mais recentes no feed de dev do MyGet. Você vai querer usar os pacotes System.Net.Http.dll mais recentes, que a partir de hoje são:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

versão 4.4.0-beta-24913-02.

Você pode usar pacotes de feed de desenvolvimento alterando os feeds de origem do pacote NuGet com ferramentas de linha de comando ou Visual Studio.

Instruções:

Linha de comando:
Adicione o seguinte em nuget.config, emelemento:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Estúdio visual:
No VS, Ferramentas-> Opções-> Gerenciador de Pacotes Nuget-> Fontes de Pacotes -> Adicionar, em Fonte, use este url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Em ambos os casos, certifique-se de listar o feed dev MyGet como o primeiro feed da lista.

E para resumir a correção em dotnet / corefx # 15036, acabamos com 100% de compatibilidade de aplicativo com a superfície da API .NET Framework System.Net.Http 4.0 original e 100% de compatibilidade de aplicativo ao usar WebRequestHandler .

Em termos de nível de suporte para as propriedades mais novas adicionadas a HttpClientHandler (que fazem parte do .NET Core 1.1 e posteriores), o seguinte resume o comportamento esperado dessas propriedades mais novas ao executar no destino 'net46' :

1) public bool CheckCertificateRevocationList
Lança PlatformNotSupportedException

2) public X509CertificateCollection ClientCertificates
Implementado

3) public ICredentials DefaultProxyCredentials
Implementado

4) public int MaxConnectionsPerServer
Implementado em relação à lógica ServicePoint atual

5) public int MaxResponseHeadersLength
Implementado

6) IDictionary públicoPropriedades
Implementado

7) Função públicaServerCertificateCustomValidationCallback
Implementado, exceto que o primeiro parâmetro é sempre nulo devido à incapacidade atual de mapear HttpWebRequest internos para HttpRequestMessage

8) SslProtocols públicos SslProtocols
Joga PlatformNotSupportedException

Woo hoo! Obrigado rapazes!

Alguém teve a chance de validar os bits de @davidsh ? Nós realmente gostaríamos de receber alguma validação ponta a ponta nos cenários 7-ish que foram sugeridos neste tópico.

Conseguimos validar a reprodução simplificada de @onovotny até agora. Seria ótimo obter mais algumas confirmações sobre repros que não temos localmente. Obrigado!

Assim que tivermos isso, iremos mover a mudança para o branch 1.1 e lançar um patch - esperançosamente na próxima semana.

Vou fazer alguns testes esta semana. Acabei de ser puxado para uma escalação, então não posso começar em um ou dois dias, pelo menos.

@dluxfordhpf obrigado! Agradeço sua ajuda.

Acabei de instalar 4.4.0-beta-24913-02 em meu projeto. Parece ajudar no meu caso.

Caso: Auto-hospedagem ASP.NET Core de um serviço do Windows executando o framework completo 4.6.2. dependência NETStandard.Library 1.6.1 me força a usar System.Net.Http 4.3.0.

O feed myget é muito lento em minha experiência. Demorou alguns minutos para instalar System.Net.Http 4.4.0-beta-24913-02
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 82079ms
OK https://dotnet.myget.org/F/dotnet-core/api/v3/registration1/system.net.http/index.json 93813ms

Obrigado @ annemartijn0 pela confirmação e por descrever o cenário!

Atualmente, está levando de cinco a sete minutos para que esta página retorne um resultado:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Por que a Microsoft está terceirizando infraestrutura vital para essas pequenas empresas sombrias e pequenos sites estúpidos? Você está realmente escolhendo colocar seu negócio E meu negócio em uma empresa na Bélgica chamada Tech Tomato?

De qualquer forma ... Eu já tinha um feed myget, mas ele não estava puxando esta biblioteca até depois que reiniciei o Visual Studio, cliquei no botão "atualizar" em uma caixa de diálogo em algum lugar e reiniciei o Visual Studio uma segunda vez. No momento, estou digitando isso enquanto o Visual Studio 2015 tenta restaurar meus pacotes.

Atualização: Visual Studio ainda está agitado, mas minha atualização da página myget finalmente apareceu. Mostra talvez uma dúzia de downloads por dia desta versão da biblioteca. Enquanto isso, o Visual Studio resume isso como "System.Net.Http - 75.8K downloads." Sempre achei que essas estatísticas estavam me dizendo a coisa errada, mas aqui está um ótimo exemplo de por que não é o que eu quero. No mínimo, diga-me o status da versão atual versus o resumo para que eu não me torne um testador alfa sem querer sem optar explicitamente pela loucura durante este momento absurdo na história do .NET.

5 horas depois e ainda não consigo tentar este patch:

Attempting to gather dependency information for package 'System.Net.Http.4.4.0-beta-24913-02'
with respect to project '...', targeting '.NETFramework,Version=v4.6.1'

Cinco minutos mais tarde...

Package 'System.Net.Http 4.4.0-beta-24913-02' is not found in the following primary source(s):
'https://dotnet.myget.org/F/dotnet-core/api/v3/index.json'. Please verify all your online package
sources are available (OR) package id, version are specified correctly.

.NET é um incêndio de pneu.

Calma, @chadwackerman . Você _optou por_ seu feed beta / alfa / não de produção, então isso significa que você está pronto para evitar problemas, etc. Dito isso, tenho usado myget há muito tempo (assinatura paga) e tenho poucos problemas com isto. Então, talvez .. apenas talvez .. pode ser o seu computador / conexão de rede / qualquer coisa? (Eu tive grandes ganhos usando MyGet nos últimos 12 meses).

.NET não é um incêndio de pneus, agora. Claro, há _grandes_ de queijo sendo movidos e muitas peças móveis e outras coisas que podem (e dão) dar errado. Mas há muitas pessoas fazendo grandes coisas com os bits RC e RTM lançados. Eu pessoalmente decidi usar apenas material de lançamento público - nem mesmo BETA ou RC mais. Portanto, minhas expectativas são: menos problemas, mas tenho que esperar mais. Então, se você está achando algumas dessas coisas realmente frustrantes para você - talvez apenas espere um pouco mais para que algum desse trabalho de desenvolvimento chegue ao status RTM.

O trabalho da equipe corefx (e os outros no mundo .NET-core) tem sido ótimo e uma excelente recepção em relação ao github / open-and-transparent, em comparação com o bad-ole-Balmer-day, então vamos todos tentam permanecer positivos e úteis para os mantenedores do repositório. Todos aqui são humanos e estão apenas tentando tornar o mundo um lugar melhor: um byte de cada vez.

@chadwackerman Parece que o feed myget está sofrendo agora. Não estou 100% certo de como o myget funciona, mas acho que se você tiver um host dedicado ("dotnet.myget.org"), os feeds são realmente alugados e têm limites de QoS.

Indo aqui mostra que o pacote existe, mas demora um pouco para aparecer: https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

@PureKrome Sou um ex-gerente de desenvolvimento da Microsoft que foi solicitado a verificar esta compilação (veja acima). Depois de escalar pessoalmente esse bug internamente, porque ninguém na equipe .NET estava ciente dele. E agora eles não conseguem me enviar um binário maldito.

Eu reconheço um incêndio de pneu quando vejo um. Eu costumava colocá-los para ganhar a vida para a Microsoft.

@chadwackerman Eu posso entender sua frustração com os problemas com o feed. No entanto, o xingamento ('pequenos sites estúpidos' e 'pequenas empresas obscuras') está fora de ordem.
A Tech Tomato é fundada / administrada por indivíduos qualificados: @maartenba , MVP premiado por seu antigo empregador e @xavierdecoster , atual funcionário da MS; em um país (do qual tenho parcialidade) que incentiva a inovação. O nome da empresa é pouco relevante e o fato de a empresa ter sido fundada na Bélgica mostra que a equipe do .NET Core vai além de Redmond, WA em busca de soluções.
Aguardo suas contribuições construtivas para ajudar a resolver esse problema.

Conteúdo editado pelo moderador

Um relatório do Código de Conduta foi submetido contra alguns dos comentários neste tópico e, como resultado, removemos algum material que julgamos ter violado esse código. Se você tiver alguma dúvida ou preocupação sobre isso, envie um e-mail para [email protected].

@chadwackerman sua posição anterior na empresa não lhe dá o direito de criticar ninguém ou de xingar. Além disso, a grande maioria de suas 'contribuições' para este tópico não foram apenas não construtivas, mas mesquinhas, infantis e fora do tópico. Por favor, vá em outro lugar.

Ei pessoal - Martin da .NET Foundation aqui, queria explicar isso .

Compreendo perfeitamente que o problema original levantado por este tópico seja frustrante e que as pessoas queiram que ele seja corrigido. Eu também entendo algumas das preocupações mais amplas em torno da qualidade e entrega e da força do sentimento em geral. A equipe está trabalhando para resolver esse problema e continuará a manter o pessoal atualizado.

Enquanto isso, mantenha o tom profissional e evite fazer comentários que possam ser interpretados como ataques pessoais a outras pessoas. Eu fui deliberadamente leve nas edições feitas, pois queria preservar um pouco da força do sentimento e não desinfetar as coisas, mas, por favor, mantenha as coisas civilizadas.

Alguém mais tentou entrar em contato com a Tech Tomato? Nenhuma resposta às minhas perguntas.

Esta é a aparência de se você tentar realizar um trabalho real classificando os avisos de construção estranhos após adicionar o feed:

Attempting to gather dependency information for package
'System.Net.Http.4.4.0-beta-24913-02' targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 1.55 min

Attempting to gather dependency information for package 
'Microsoft.Extensions.Configuration.Json.1.1.0' targeting '.NETFramework,Version=v4.6.1' 
Gathering dependency information took 2.2 min

... e assim por diante.

E este link ainda leva mais de 5 minutos para mostrar uma página:
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

O fato de a) não ter sido corrigido ainda b) ser ignorado pela comunidade ec) tolerado pela equipe .NET como parte do desenvolvimento do dia a dia serve para reforçar as falhas óbvias no processo, ferramentas, cultura e gerenciamento que levaram a esse bug para começar com - mais o próprio bug sendo ignorado por meses até que eu o escalasse internamente.

Estou ansioso pelo post-mortem prometido por @karelz .

Oi chad,

Esse tempo de carregamento da página é algo que estamos examinando. O tempo de restauração do NuGet não é normal. Se possível, você pode entrar em contato conosco (MyGet) através do suporte em MyGet.org mencionando sua versão do NuGet.exe em uso, bem como um rastreamento com a opção -Verbosity Detailed habilitada? Isso certamente nos ajudará a identificar quaisquer problemas de desempenho.

Obrigado!

Package Manager Console Host versão 3.5.0.1996

Analisarei como obter logs da linha de comando conforme o Visual Studio vai de sólido para instável depois que eu adicionar o feed myget.org. E quando ocorre um erro ao puxar um pacote para baixo, a coisa toda tomba.

ps @karelz : incêndio em pneus.

Você pode tentar esta linha de comando usando o NuGet.exe mais recente (noturno) em www.nuget.org/downloads?

Comando exato: NuGet.exe install System.Net.Http -Version 4.4.0-beta-24913-02 -Verbosity detalhado

Isso deve gerar todas as ações de download intermediárias também. Obrigado!

@maartenba :

No link que você enviou, "mais recente" aponta para https://dist.nuget.org/win-x86-commandline/latest/nuget.exe. Essa é a versão que eu já tenho, então não acho que seja uma noite.

Baixei o pacote noturno NuGet.CommandLine.4.0.0-rtm-2254.nupkg, executei a instalação do nuget.exe nele e ele falhou ao tentar puxar os arquivos de myget.org. FYI: 1,5 segundos para retornar um 404 de dotnet.myget.org.

Se esta não for a maneira correta de instalar uma compilação noturna ou pacote local, informe. Você pode me enviar um e-mail com este nome de usuário no gmail se preferir colocá-lo off-line.

Ainda feliz em ajudar, mas ... uau. As coisas realmente deveriam estar se movendo na direção da simplicidade, não eu solucionando problemas do host de pacote secundário para o host de pacote primário usando uma queda noturna do gerenciador de pacotes que, apesar de estar na versão 4.0.0-rtm, de alguma forma tem cinco métodos manuais distintos para atualizando-se em sua página de distribuição, cada uma das quais requer intervenção manual do usuário.

ps @karelz ... ah, deixa pra lá. :)

Concordo totalmente, mas os logs seriam muito úteis para descobrir onde está o gargalo (se o host do pacote secundário, o próprio cliente, um nó CDN louco, raios cósmicos, ...). Entraremos em contato com você off-line para ver se podemos descobrir isso. Agradeço muito sua ajuda nisso.

Eu mesmo percebi que myget.org é muito lento, mas consegui instalar o pacote em questão com sucesso em um tempo "razoável" (em uma rede Wi-Fi pública).

OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms
Installing System.Net.Http 4.4.0-beta-24913-02.

Definitivamente, devemos examinar a lentidão geral do myget.org, mas provavelmente fora do escopo deste problema - afinal, não é um cenário típico de cliente. @maartenba onde é o melhor lugar para discutir isso?
Aqui (neste problema específico), vamos nos concentrar em como desbloquear a validação de ponta a ponta, por exemplo, usando algumas soluções alternativas criativas.
Também me pergunto se outras pessoas foram bloqueadas tanto quanto @chadwackerman , ou se a experiência de @chadwackerman é extremamente ruim, em comparação com outras.

@chadwackerman, visto que o objetivo principal aqui é validar o cenário de ponta a ponta, gostaria de saber se você pode fornecer as etapas do seu cenário? Outra pessoa aqui (que não está tão bloqueada pelo uso do myget.org quanto você) poderia concluir a validação nesse caso. Isso deve diminuir sua dor e perda de tempo do seu lado. Claro, presumindo que seja factível e barato de sua parte.

A alternativa de último recurso, que eu gostaria de evitar, é pular totalmente a validação do seu cenário - se conseguirmos validar alguns outros cenários ponta a ponta, podemos estar ok (assumindo o pior cenário em que @maartenba não será capaz de solucionar sua experiência péssima no myget.org :().

@karelz colocando isso offline com Chad, apresentará um relatório aqui assim que descobrirmos o que está acontecendo.

Fatos de fundo:

• O feed de myget.org é usado por compilações diárias, CI, dev-workflow, etc. Portanto, ele é muito trabalhado diariamente. Nenhum desses problemas de desempenho se manifestam nesses cenários (quando ocorriam no passado, agimos de acordo com eles, porque eles afetaram o fluxo de trabalho de nossos desenvolvedores - aumentamos o tempo de sincronização de 30-60 minutos para <5 minutos nos últimos meses). Meu entendimento é que é raro alguém na equipe .NET ou na comunidade usar o feed myget no VS - que, IMO, explica por que o mau desempenho passou despercebido nesse cenário.
• Este problema foi encaminhado para mim por um colega de trabalho neste tópico em 09/12/2016 - é por isso que entrei na discussão aqui. Não tenho conhecimento de nenhuma outra escalada interna. Visto que continuamente empurro esse problema internamente em várias equipes (quase diariamente), acho que estou ciente de todos os eventos relacionados a esse problema.

@karelz Sim,

Desde então, verifiquei que MyGet.org está se comportando mal de várias máquinas de amigos nas costas leste e oeste. O meu é uma instalação limpa recente do Visual Studio 2015, sem suplementos, definitivamente sem ReSharper. O feedback do usuário e o tratamento de erros no Visual Studio são ruins. Mesmo aqui, outros usuários relatam atrasos semelhantes. Vou deixar isso de lado por enquanto para liberar o thread, mas não vamos fingir que MyGet não está bloqueado e todo o sistema de empacotamento do NuGet (e a capacidade do NuGet de se atualizar) não cheira levemente a borracha queimada e também não é um fator que contribui para este bug. Originalmente como parte da causa raiz e ainda hoje como parte da tentativa de testar e enviar a correção.

Não tenho certeza se devemos continuar discutindo isso neste tópico ou abrir outro tópico para isso. Enfim: relatório de status!

Estamos em contato com @chadwackerman por e-mail - obrigado Chad pelo log que você enviou!

Sobre a "lentidão" - o perfil preliminar nos diz que isso é causado pelo número de versões do pacote e o impacto desse fato no tamanho do download dos dados do protocolo. Por exemplo, alguns pacotes requerem 4 MB de dados JSON para serem baixados e analisados ​​para reunir metadados. Isso causa um grande pico de uso de memória no cliente NuGet e a necessidade de analisar uma carga de barco de dados JSON - definitivamente espaço para melhorias, embora os nightlies 4.0.0 do cliente pareçam se comportar melhor.

No lado do MyGet, implementaremos paginação para esses blobs de protocolo para reduzir o tamanho do download no protocolo. Pode levar uma semana para que isso vá ao ar. Também faremos o perfil do servidor e do cliente nessas solicitações e veremos se há espaço para otimização em ambos os lados.

Também estamos tentando acelerar o tempo de carregamento da página (mas isso é secundário, ter instalação / restauração rápida é a prioridade).

Após horas de experimentação, consegui atualizar para System.Net.Http 4.4.0-beta-24913-01 sem travar o Visual Studio. Em seguida, tentei atualizar de 24913-01 para 24913-02 e recebi um erro adequado em vez de um travamento.

Estamos em 2017 e a atualização da compilação noturna do componente HTTP central para todo o sistema, de "compilação de segunda-feira" a "compilação de terça-feira", leva mais de cinco minutos de duração em um i7 de 8 núcleos e requer mais de 4 GB de RAM.

O projeto em questão é um webjob (um aplicativo de linha de comando renomeado) que consiste em 27 linhas de código.

Curiosamente, @karelz afirma que isso funciona muito bem para toda a equipe .NET e que ele não tem nenhum problema em sugar o binário, mesmo enquanto toma um café com leite no Starbucks local.

Consegui instalar o pacote em questão com sucesso em um tempo "razoável" (na rede Wi-Fi pública).
https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.4.0-beta-24913-02 971ms

Aqui estão alguns fatos alternativos:

Tentativa de coletar informações de dependência para o pacote 'System.Net.Http.4.4.0-beta-24913-02' com relação ao projeto 'webjob', visando '.NETFramework, Version = v4.6.1'
A coleta de informações de dependência levou 4,22 min
Tentando resolver dependências para o pacote 'System.Net.Http.4.4.0-beta-24913-02' com DependencyBehavior 'Lowest'
Resolvendo ações para instalar o pacote 'System.Net.Http.4.4.0-beta-24913-02'
Ações resolvidas para instalar o pacote 'System.Net.Http.4.4.0-beta-24913-02'
System.OutOfMemoryException: exceção do tipo 'System.OutOfMemoryException' lançada.
em Newtonsoft.Json.Linq.JContainer.ReadContentFrom (JsonReader r)
em Newtonsoft.Json.Linq.JContainer.ReadTokenFrom (leitor JsonReader)
em Newtonsoft.Json.Linq.JObject.Load (leitor JsonReader)
em NuGet.Protocol.HttpSource. <> c.b__15_0 (stream stream)

Sim, vocês podem por favor mover este problema MyGet / NuGet para um novo problema? Não tem relação com o problema original.

@onovotny - Considere reabrir seu problema para. Este problema agora é superlongo, então a usabilidade do problema foi reduzida.

@richlander, em vez de policiar o thread, você tentaria instalar a correção e relatar se ela resolver seu problema específico? Todos parecem estar bloqueados por esse problema importante, mas as pessoas preferem jogar pingue-pongue no GitHub do que fazer o trabalho real para testar a correção.

Teste todos os ~ 7 cenários ponta a ponta relatados pela comunidade (peça ajuda da comunidade, forneça as etapas para consumir pacotes mestre no myget)

Quais são os 7 cenários? Todos podem ajudar?

@richlander Eu ficaria feliz em reabrir um problema. Você está apenas me procurando para clonar este aqui com as atualizações de @karelz ? Não tenho certeza do que a pergunta é.

Meu caso de uso estava trabalhando com a API de armazenamento do Azure, que estava funcionando pela última vez em 4.0.1-rc2-24027. Parece que agora está funcionando. Fiz apenas um teste rápido, pois demorou cerca de 20 minutos para atualizar todos os pacotes em meus projetos do MyGet.

@onovotny Não abra novamente. Temos momentum aqui e estamos a centímetros de pelo menos uma resolução parcial. O tópico é opressor para qualquer um que está entrando agora, mas como qualquer outro problema não resolvido de longa data que revela problemas mais profundos, tem que ser. O GitHub é péssimo para coisas assim.

Verifiquei que o novo binário funciona de forma compatível em um aplicativo local. Nenhuma surpresa nisso. Em seguida, tentei cortar e colar essas dependências no meu projeto webjob e não consegui fazê-lo funcionar no Azure. O Webjob carrega bem, mas falha quando acionado, incapaz de carregar System.Net.Http. Obviamente, a culpa é minha e eu sei como corrigi-la. Mas estou quase de volta onde estava quando este bug foi aberto pela primeira vez: remapeamentos de ligação ajustados e quando eu toco em NuGet tudo desaba, perco uma quantidade enorme de tempo e meu projeto passa em todos os testes localmente, mas quebra no tempo de execução na implantação .

Portanto, nossos cenários são:

1. Um pacote dependente (Raven.Database) usa WebRequestHandler, que estava interrompendo no tempo de execução, conforme relatado neste problema.
2. Nosso código usa o novo tipo e propriedades HttpClientHandler.

Anteriormente, tentei as correções de redirecionamento de vinculação, mas que levaram a conflitos, acabei usando hacks (injeção de reflexão, duplicação e modificação de código de terceiros) para contornar os problemas.

Eu atualizei para a versão beta e removi todo o código de hack e tudo (nosso aplicativo, de ponta a ponta, do navegador ao banco de dados) parece estar funcionando localmente! Ainda não experimentei o código na plataforma Azure, então vou confirmar quando isso for feito, mas considero esse progresso significativo.

Além disso, ao atualizar os pacotes, achei tolerável usar o Visual Studio Package Manager Console e usar este comando para atualizar os pacotes (em vez de adicionar outra configuração de feed e usar a IU, o que é incrivelmente doloroso):

Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core

Isso levou 6 minutos e 53 segundos para que 20 projetos fossem atualizados.

Observe que todos os nossos projetos tiveram o seguinte redirecionamento de ligação gerado automaticamente, eu não precisei mexer em nenhum redirecionamento de ligação:

    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
      </dependentAssembly>
    </assemblyBinding>

Quase hora de high-fives!

@jahmai Quando usei essa linha de comando, ela não atualizou minha referência de 4.0 para 4.2 nem adicionou os sinalizadores de cópia necessários. Certifique-se de que estejam definidos para System.Net.Http e dependências e deve funcionar bem no Azure.

Nosso cenário é uma dependência direta de tipos em System.Net.Http.
Testei Update-Package System.Net.Http -Version 4.4.0-beta-24913-02 -Source https://dotnet.myget.org/F/dotnet-core em um projeto e até agora parece funcionar bem. Boas notícias.
Atualização Esqueci de mencionar que os redirecionamentos de vinculação de 4.0.0.0 para 4.2.0.0 foram aplicados automaticamente.

Com relação aos problemas de Nuget / MyGet, obtive a seguinte saída para este único projeto:

A coleta de informações de dependência levou 37,47 segundos
A execução de ações nuget levou 35,15 segundos
Tempo decorrido: 00: 01: 14.7537429

Observe que estou no fuso horário UTC +01: 00, não sei quando MyGet está recebendo mais tráfego.

@pollax Obrigado. Encontramos o problema (veja meu último comentário acima) - combinação cliente + servidor. Trabalhando para torná-lo melhor.

Posso confirmar que usando a biblioteca beta System.Net.Http de MyGet funcionou para meu cenário:

• Aplicativo de console .NET 4.6 com dependência de uma biblioteca que usa System.Net.Http

Demorou cerca de 90 segundos para o pacote nuget baixar de MyGet e o bindingRedirect no app.config foi aplicado corretamente.

Fico feliz em ajudar a testar mais cenários se eles tiverem sido descritos em algum lugar.

Efeito colateral interessante: adicionar o 4.4.0-beta de uma biblioteca .NET somente para Windows interrompeu a implantação de um aplicativo .NET Core no Linux.

"dotnet restore" é codificado para tempos de recuperação de pacote de 60 segundos. E não há bandeira para selecionar apenas uma plataforma específica, como suporte para "publicação dotnet". Portanto, para uma biblioteca de plataforma cruzada, seu minúsculo nó de trabalho do Linux baixa um monte de binários do Windows desnecessariamente - depois atinge o tempo limite e falha quando atinge MyGet. Curiosamente, o problema de falta de memória que trava o Visual Studio em uma máquina de 32 GB não afeta um trabalhador Linux de 0,75 GB porque, em vez disso, ele muda até a morte.

Sim, eu registrei isso em outro lugar. E sim, está relacionado a esse bug, mesmo que você ainda não o veja.

Obrigado a todos nos ajudando a verificar os cenários! Recebemos até agora 5 confirmações - veja a lista detalhada com links na postagem mais importante. Eu considero uma validação boa o suficiente para passar para os próximos estágios.

• [4.a.ii] Ainda estou perseguindo a análise do NuGet.
• [5.a] Vou pedir a @davidsh para preparar o PR contra o branch release / 1.1.0.

• [5.b] Estou preparando o processo para liberação (precisamos da aprovação do nível de diretor, mas dado o impacto sobre os clientes, não espero nenhum retrocesso).

• Estou preparando informações oficiais sobre o lançamento do patch - listando todas as alterações técnicas e soluções alternativas (obrigado a @davidsh pelos dados).

Se alguém descobrir alguma preocupação entretanto (relacionada a este problema específico), diga-o o mais rápido possível. Dedos cruzados.

@onovotny - Parece que o problema está progredindo agora, então vamos continuar com esse problema. É ótimo ver que as pessoas estão fazendo um progresso positivo.

@karelz Você pode marcar meus cenários que incluem a linha de comando 4.6 (Azure webjob) com dependência do ServiceBus e um aplicativo 4.6 com dependências no Azure Batch. Além disso, um terceiro aplicativo com dependências de AWS e Dropbox, que anteriormente movi para o .NET Core apenas para me livrar desse problema (tirei uma versão antiga para testar hoje).

dotnet restauração problema revivido em https://github.com/NuGet/Home/issues/2534 , Contribuinte Aliança fixo backchannel, pneus chutou https://github.com/Azure/azure-storage-net/issues/372 , MyGet logs enviados, logs de desempenho adicionais solicitados em https://github.com/dotnet/cli/issues/5328 , e eu comprei um saco enorme de pipoca para a discussão post mortem.

Obrigado @chadwackerman pela sua ajuda e confirmação! Desculpe pelo problema que você encontrou no caminho.
Eu atualizei a postagem mais importante.

Da minha lista acima:

Estou preparando informações oficiais sobre o lançamento do patch - listando todas as alterações técnicas e soluções alternativas (obrigado a @davidsh pelos dados).

Eu adicionei informações à postagem mais importante - consulte a seção "Impacto da mudança - Mudanças importantes" para uma lista de mudanças técnicas importantes (4), cada uma com uma solução alternativa.

Bibliotecas NuGet afetadas pela alteração técnica significativa (descrita na postagem mais importante) - felizmente "apenas" 4 bibliotecas NuGet que usam qualquer uma dessas novas APIs:

System.Private.ServiceModel_4.3.0

• https://www.nuget.org/packages/System.Private.ServiceModel/
• Autor: dotnetframework
• Downloads: 11K (versão mais recente) / 800K (total)
• Descrição: Pacote de implementação interno não destinado ao consumo direto. Não faça referência diretamente. Fornece implementação de pacotes System.ServiceModel.
• Notas:
• Status: Pacote não afetado - @zhenlan @mconnew da equipe WCF confirmou que usam as propriedades apenas em compilações do .NET Core. No Desktop, eles recorrem aos binários integrados do Desktop.

Consul_0.7.2.1

• https://www.nuget.org/packages/Consul/
• Nome: Cônsul
• Autor: https://www.nuget.org/profiles/highlyunavailable
• Downloads: 500 (versão mais recente) / 65K (total)
• Descrição: https://github.com/PlayFab/consuldotnet/blob/master/CHANGELOG.md
• Notas:
  
  
  
  • 2 usos: https://github.com/PlayFab/consuldotnet/search?utf8=%E2%9C%93&q=ServerCertificateCustomValidationCallback
  
  
  • Problema arquivado no GitHub: https://github.com/PlayFab/consuldotnet/issues/79
  
  
  • Email enviado ao autor via nuget.org
  
  
• Status: pacote não afetado (problema de GitHub https://github.com/PlayFab/consuldotnet/issues/79 fechado)

Octopus.Client_4.6.1

• https://www.nuget.org/packages/Octopus.Client/
• Autor:
  
  
  
  • https://www.nuget.org/profiles/paulstovell
  
  
  • https://www.nuget.org/profiles/OctopusDeploy
  
  
• Downloads: 250 (versão mais recente) / 55K (total)
• Descrição: Nenhum
• Notas:
  
  
  
  • Problema arquivado no GitHub: https://github.com/OctopusDeploy/OctopusClients/issues/121
  
  
  • Email enviado para o alias de suporte: [email protected]
  
  
  • Email enviado ao (s) autor (es) via nugget.org
  
  
• Status: pacote não afetado (detalhes no problema do GitHub https://github.com/OctopusDeploy/OctopusClients/issues/121)

Geotab.Checkmate.ObjectModel_5.7.1701

• https://www.nuget.org/packages/Geotab.Checkmate.ObjectModel/
• Nome: SDK Geotab
• Autor: https://www.nuget.org/profiles/neilcawse
• Downloads: 150 (versão mais recente) / 10K (total)
• Descrição:
  
  
  
  • Biblioteca SDK para acessar bancos de dados de clientes MyGeotab
  
  
  • Veja uma lista completa de alterações em https://my.geotab.com/sdk/default.html#/whatsNew
  
  
• Notas:
  
  
  
  • Email enviado ao autor (CEO geotab.com) via nugget.org
  
  
• Status: Proprietário contatado, aguardando resposta

Desculpe pela inconveniência para todos os autores dos pacotes afetados.

No travamento / troca do Visual Studio / NuGet no Linux: a razão para isso está na maneira como o protocolo NuGet funciona. Eu documentei as descobertas neste problema: https://github.com/NuGet/Home/issues/4448

No lado do MyGet, implantaremos uma mudança após o fim de semana (atualmente em teste, ETA em produção na segunda-feira, 7 de fevereiro) que ameniza o lado do servidor.

A correção no lado MyGet está ativa. Deve funcionar bem no Visual Studio. Ao usar NuGet.exe, certifique-se de usar o NuGet.exe incorporado em https://dotnet.myget.org/F/nuget-build/api/v2/package/NuGet.CommandLine (4.0 noturno) - o 3.5 parece não conseguir descobrir dependências (mas nem sempre). Bug registrado: https://github.com/NuGet/Home/issues/4512

Obrigado pelo mergulho profundo neste @maartenba. Nunca subestime o impacto que mesmo uma pequena correção de ferramenta pode ter!

Interessante que toda a equipe .NET poderia perder a falha do Visual Studio e o problema do NuGet.

Certa vez, pedi a uma sala com mais de 80 desenvolvedores da Microsoft que levantassem a mão se alguém estivesse tendo problemas para definir pontos de interrupção no depurador. Eu tenho duas mãos. O compilador mudou o formato do símbolo, você não poderia construir o projeto sem o compilador mais recente, mas os depuradores ainda não haviam sido atualizados.

Durante meses, ninguém conseguiu definir um ponto de interrupção. Em duas plataformas, você não conseguia nem mesmo obter um rastreamento de pilha! Sou chamado para o laboratório de construção à 1h porque sou a única outra pessoa por perto, recebo uma tela cheia de montagem de um processador do qual nunca vi documentos, recebo um backtrace e o depurador trava no depurador.

Quando você altera o formato do projeto enquanto está alterando o código que analisa o formato do projeto, enquanto você está testando uma nova versão do gerenciador de pacotes que se conecta à nova versão do Visual Studio - resultados como este. Um mortal só pode lidar com tantas mudanças de uma vez e é por isso que os desenvolvedores continuam jogando a bola em todos os lugares. Nós e eles!

Se alguém quiser um script PowerShell simples para corrigir bindingRedirect em todos os app.config, aqui está. Provavelmente não é a melhor solução, mas agora eu tenho um projeto com muitos subprojetos webjobs e é realmente frustrante alterar manualmente todas as ligações de arquivos após atualizar algum pacote.

param(
    [string]$SourceDirectory,
    [string]$Package,
    [string]$OldVersion,
    [string]$NewVersion
)

Write-Host "Start fixing all app.config"

[array]$files = get-childitem $sourceDirectory -Include app.config App.config -Recurse | select -expand FullName
foreach ($file in $files)
{
    Write-Host $file
    $xml = [xml](Get-Content $file)
    $daNodes = $xml.configuration.runtime.assemblyBinding.dependentAssembly
    foreach($node in $daNodes)
    {
        if($node.assemblyIdentity.name -eq $package)
        {
            $updateNode = $node.bindingRedirect
            $updateNode.oldVersion = $OldVersion
            $updateNode.newVersion =$NewVersion
        }
    }
    $xml.Save($file)
}

Write-Host "Done"`

Exemplo de uso:
./scripts/FixAppConfig.ps1 -SourceDirectory "--project-path--" -Package "System.Net.Http" -OldVersion "0.0.0.0-4.3.0.0" -NewVersion "4.0.0.0"

Quando isso se tornará público novamente? :)

Nossa mudança chegou ao branch release / 1.1.0 na terça - versão do pacote 4.3.1. Todos os pacotes no branch foram invertidos para estáveis ​​ontem (esforço independente, mas nos ajuda também :)).
@davidsh fará um teste de sanidade no feed myget (ETA: hoje), então vamos pedir uma última validação aqui pela comunidade (ETA: hoje, EOD). Assim que tivermos a validação final dessa compilação, enviaremos o pacote para NuGet. Minha expectativa é que demore menos de uma semana.

Tivemos um atraso no andamento e na comunicação, pois tínhamos que convencer o shiproom, porque esse é o melhor e único conserto.
Além disso, estamos preparando um plano (com base nos comentários do shiproom) para interromper o envio deste pacote fora da proibição inteiramente em .NET Standard 2.0 e encaminhar todas as funcionalidades para a estrutura de desktop embutida (a funcionalidade do .NET Core permanecerá intacta) - ou seja, nenhum redirecionamento de ligação será necessário se você visar o .NET Standard 2.0. Assim que tiver detalhes sobre o impacto em todos os cenários, atualizarei este tópico (em 1-2 semanas).

Essas são boas notícias e tornarão o netstandard2.0 mais fácil de usar.

@davidsh verificou o pacote 4.3.1 do branch de lançamento (aviso: myget estava muito lento para ele - 5 minutos)
Aqui estão as etapas para validar:

Experimente os pacotes mais recentes no feed de dev do MyGet. Você vai querer usar a última compilação STABLE (não Prerelease) do pacote System.Net.Http.dll - 4.3.1 :
https://dotnet.myget.org/feed/dotnet-core/package/nuget/System.Net.Http

Você pode usar pacotes de feed de desenvolvimento alterando os feeds de origem do pacote NuGet com ferramentas de linha de comando ou Visual Studio.

Instruções:

Linha de comando:
Adicione o seguinte em nuget.config, emelemento:

<add key="myget.org dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json" />

Estúdio visual:
No VS, Ferramentas-> Opções-> Gerenciador de Pacotes Nuget-> Fontes de Pacotes -> Adicionar, em Fonte, use este url, https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Em ambos os casos, certifique-se de listar o feed dev MyGet como o primeiro feed da lista.

[EDITAR]
Espere um redirecionamento de vinculação para 4.1.1.0 em seu arquivo de configuração:

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Eu atualizei a postagem principal 'Plano de execução' com as próximas etapas:

• 5.c Validação final / última de (a maioria) dos ~ 7 cenários de ponta a ponta - pessoas que ajudaram antes (ou qualquer outra pessoa), você pode responder assim que verificar com a breve descrição do cenário? Obrigado! (estamos quase lá)
  
  
  
  • cc: @ annemartijn0 @karelkrivanek @jahmai @pollax @MikeGoldsmith @chadwackerman @dluxfordhpf @onovotny
  
  
• 5.d Publique o pacote em myget.org

Tentei verificar, mas estou recebendo erros ao tentar instalar esse pacote.

Quando fiz minha validação, fiz com um projeto totalmente novo.

Suspeito que o erro que você está obtendo com "Falha ao atualizar redirecionamentos de ligação" é devido ao downgrade nas versões de pacote e assembly. Seu projeto atual parece ser baseado nos pacotes do branch [master]. System.Net.Http.4.4. * É a numeração do pacote da ramificação [master] (parte do pré-lançamento do .NET Core 2.0). Ele tem uma versão de montagem para System.Net.Http que é 4.2. *.

O pacote System.Net.Http versão 4.3.1 é um pacote STABLE (não de pré-lançamento) e é criado a partir do branch de serviço .NET Core 1.1 (compatível com o lançamento de serviço .NET Core 1.1.1). Ele contém um binário de dll System.Net.Http com uma versão de assembly diferente.

Acho que o bug que você descobriu é quando o Visual Studio / NuGet está tentando reescrever seus redirecionamentos de ligação para a versão alterada do assembly de System.Net.Http.

Portanto, você pode tentar criar uma nova solução / projeto. Ou talvez exclua seus redirecionamentos de ligação e coloque-os de volta.

PARA SUA INFORMAÇÃO. Meu log da instalação do meu pacote:

Attempting to gather dependency information for package 'System.Net.Http.4.3.1' with respect to project 'Net46HttpTest3', targeting '.NETFramework,Version=v4.6.1'
Gathering dependency information took 4.27 min
Attempting to resolve dependencies for package 'System.Net.Http.4.3.1' with DependencyBehavior 'Lowest'
Resolving dependency information took 0 ms
Resolving actions to install package 'System.Net.Http.4.3.1'
Resolved actions to install package 'System.Net.Http.4.3.1'
Retrieving package 'System.Security.Cryptography.Encoding 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Primitives 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.Algorithms 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Security.Cryptography.X509Certificates 4.3.0' from 'CoreFx Dev Feed'.
Retrieving package 'System.Net.Http 4.3.1' from 'CoreFx Dev Feed'.
  GET https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1
Adding package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Encoding.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
  OK https://dotnet.myget.org/F/dotnet-core/api/v2/package/System.Net.Http/4.3.1 302ms
Installing System.Net.Http 4.3.1.
Added package 'System.Security.Cryptography.Encoding.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Encoding 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Primitives.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Primitives 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.Algorithms.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.Algorithms 4.3.0' to Net46HttpTest3
Adding package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Security.Cryptography.X509Certificates.4.3.0' to 'packages.config'
Successfully installed 'System.Security.Cryptography.X509Certificates 4.3.0' to Net46HttpTest3
Adding package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to folder 'c:\users\dshulman\documents\visual studio 2015\Projects\Net46HttpTest3\packages'
Added package 'System.Net.Http.4.3.1' to 'packages.config'
Successfully installed 'System.Net.Http 4.3.1' to Net46HttpTest3
Executing nuget actions took 2.41 sec
========== Finished ==========
Time Elapsed: 00:06:40.8451462

Hm, estou confuso durante o teste. Eu atualizei para 4.3.1 e recebi o seguinte redirecionamento de ligação em meu web.config.

<dependentAssembly>
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" />
</dependentAssembly>

Esperado?
Talvez eu tenha perdido algo no início do tópico, ou talvez esta seja uma daquelas situações confusas de erros de correspondência entre versões de pacotes e versões DLL.
Também desinstalei o pacote, removi os redirecionamentos de ligação e reinstalei e obtive o mesmo resultado.

Criando e executando o Works On My Machine ™ ️.

Aliás, eu não tenho certeza porque essa versão caiu de 4.4 para 4.3.1, mas tudo bem.

A versão caiu na numeração porque a versão 4.4 será a mais recente, mas ainda é um pré-lançamento e será fornecido como parte do .NET Core 2.0. @karelz pediu às pessoas que testassem esse pacote primeiro porque a correção estava lá primeiro.

Os pacotes 4.3. * São baseados no RTM .NET Core 1.1. E haverá uma liberação de serviço disso. Portanto, o pacote atualizado com base nessa base de código é 4.3.1 para System.Net.Http (já que o pacote .NET Core 1.0 era 4.3.0 para System.Net.Http.

Talvez eu tenha perdido algo no início do tópico, ou talvez esta seja uma daquelas situações confusas de erros de correspondência entre versões de pacotes e versões DLL.

Sim, isso é confuso. A versão do pacote NuGet não é igual à versão do conjunto .NET do binário.

Para o pacote System.Net.Http 4.3.1 NuGet, ele contém um binário de System.Net.Http que tem uma versão do assembly 4.1.1.0. Então, você está obtendo os resultados certos.

Obrigado @pollax pela validação de seu cenário de ponta a ponta (postagem principal atualizada).
Esperando por mais algumas validações , antes de enviarmos como correção final no nuget.org ... quase lá ...

Minhas desculpas por termos perdido o redirecionamento de ligação nas instruções (não percebi que alteramos automaticamente a versão do assembly devido ao potencial GAC'ing, mas faz sentido).
Também peço desculpas porque myget força você a usar todos os pacotes de myget - estou acompanhando o pessoal internamente para descobrir se temos etapas para pegar apenas um pacote de myget. Pelo menos para verificações futuras.

@davidsh, você pode coordenar as validações de ponta a ponta enquanto estou ausente? Assim que tivermos ~ 3 validações, peça a @leecow / @weshaggard para publicar o pacote em nuget.org. Obrigado!

Ei pessoal,

Um pouco fora do assunto, mas eu só queria dar uma mensagem para a equipe aqui. Esse problema tem sido muito ativo e a resposta às vezes hostil. Apesar da hostilidade, sinto que a equipe de desenvolvimento aqui lidou com isso com classe.

Obrigado pelo apoio pessoal e continuem com o bom trabalho. Erros acontecem. Obrigado por corrigi-lo, entendo que leva tempo.

Aqui está outra confirmação de que a nova versão corrige o problema.

Usamos o KeyVault, passando para 4.3.1 corrigido o problema.

Olá, tenho este problema com o SignalR. Mas como faço para obter System.Net.Http 4.3.1? Eu só vejo 4.3.0 em
https://www.nuget.org/packages/System.Net.Http/

Ops, mensagens perdidas sobre CoreFx - https://dotnet.myget.org/F/dotnet-core/api/v3/index.json

Ele corrige meu problema SignalR.

Conforme observado por outros, o feed é muito lento. Alguma chance de obter 4.3.1 no canal nuget normal? É sábado às 13h30 e uau .... (8 minutos de espera pelos deps)

Tentativa de coletar informações de dependência para o pacote 'System.Net.Http.4.3.1' em relação ao projeto 'Translate \ Kumquat.Translate.Tests', visando '.NETFramework, Version = v4.6'
A coleta de informações de dependência levou 5,85 minutos
Tentando resolver dependências para o pacote 'System.Net.Http.4.3.1' com DependencyBehavior 'Lowest'
Uma ou mais restrições de dependência de pacote não resolvidas detectadas no arquivo packages.config existente. Todas as restrições de dependência devem ser resolvidas para adicionar ou atualizar pacotes. Se esses pacotes estiverem sendo atualizados, esta mensagem pode ser ignorada; caso contrário, os seguintes erros podem estar bloqueando a operação do pacote atual: 'System.Net.Http 4.3.0'
A resolução das informações de dependência levou 0 ms
Resolvendo ações para instalar o pacote 'System.Net.Http.4.3.1'
Ações resolvidas para instalar o pacote 'System.Net.Http.4.3.1'

Tentativa de coletar informações de dependência para o pacote 'System.Net.Http.4.3.1' em relação ao projeto 'Dict \ Kumquat.Dict.CE.Tests', visando '.NETFramework, Version = v4.6'
A coleta de informações de dependência levou 3,84 minutos
Tentando resolver dependências para o pacote 'System.Net.Http.4.3.1' com DependencyBehavior 'Lowest'
Uma ou mais restrições de dependência de pacote não resolvidas detectadas no arquivo packages.config existente. Todas as restrições de dependência devem ser resolvidas para adicionar ou atualizar pacotes. Se esses pacotes estiverem sendo atualizados, esta mensagem pode ser ignorada; caso contrário, os seguintes erros podem estar bloqueando a operação do pacote atual: 'System.Net.Http 4.3.0'
A resolução das informações de dependência levou 0 ms
Resolvendo ações para instalar o pacote 'System.Net.Http.4.3.1'
Ações resolvidas para instalar o pacote 'System.Net.Http.4.3.1'

@karelz Cenário da API de armazenamento do Azure revalidado com a versão 4.3.1 do MyGet.

Desculpe por não responder antes.

@tofutim reunir dependências é lento devido a muitos metadados que passam pela rede - https://github.com/NuGet/Home/issues/4448

Eu percebi isso. Algum ETA para colocá-lo no nuget.org?

@davidsh Olá David, esta será a semana 4.3.1 que chegará ao nuget? Tenho um projeto bastante complexo e parece que o tempo de espera deve ser escalonado com o número de pacotes do projeto. Ainda assim, ter uma solução é melhor do que nada. Acho que posso copiar o nupkg em algum lugar.

Tentativa de coletar informações de dependência para o pacote 'Kumquat.Translate.8.6.2' em relação ao projeto 'qi', visando '.NETFramework, Version = v4.6'
A coleta de informações de dependência levou 8,76 min

Mais recentemente, 8,76 min.

@davidsh Isso acabou de aparecer na lista de discussão OwlMQ. Posso relatar que o pacote atualizado resolve isso.

Muito obrigado à equipe por se antecipar a isso. Otimo trabalho!

Obrigado por todas as validações do pacote.

O pacote System.Net.Http 4.3.1 foi promovido para NuGet.org.

https://www.nuget.org/packages/System.Net.Http/4.3.1

Hm, muito bizarro - o cliente RavenDB agora reclama que não consegue encontrar o assembly 4.1.1

EDIT: Caveat - referências Acme.Core RavenDB.Client e referências Acme.Main Acme.Core. VS2015 não copiará System.Net.Http como dependência, mas o redirecionamento de ligação está lá -> boom. Este é o comportamento esperado? Correção bastante simples, é claro ...

Encerrando o problema como corrigido. Obrigado @davidsh e @CIPop pelo trabalho aqui!
Obrigado a todos pela paciência. E nossas desculpas pelo atraso. Próxima etapa: post-mortem (conforme prometido) - por favor, me dê cerca de 2 semanas para descobrir todos os detalhes históricos por aqui ...

@georgiosd, você pode registrar um novo problema e fornecer uma reprodução? (idealmente começando com um novo projeto)

@karelz obrigado!

PARA SUA INFORMAÇÃO:

• Eu atualizei a maioria das postagens com uma lista de cenários verificados (apenas no caso de ser necessário no futuro) e um link para o pacote.
• No futuro, pretendo examinar as etapas para usar apenas um pacote específico de myget em vez de todo o feed, para contornar o problema de obter tudo o mais recente (e também os problemas de lentidão). Vamos torcer para não precisarmos disso logo.

@karelz pergunta rápida: onde encontraremos as informações sobre a autópsia, quando ela estiver concluída. Neste tópico _ou_ em outro tópico / local?

@PureKrome Com certeza irei atualizar este tópico - é mais fácil para todos já interessados ​​em receber a notificação. Além disso, meu objetivo não é minimizar a autópsia e escondê-la das pessoas.
Provavelmente, vou criar um novo problema para a discussão (como espero alguns) ;-).
Em alto nível, pretendo cobrir:

1. Como o problema foi lançado? Como prevenir tal situação no futuro?
2. Por que demorou 6 meses para consertar? Por que não foi tratado / comunicado como um problema de alto impacto anteriormente? Como reconhecer e reagir a problemas de alto impacto no futuro?
3. Outras preocupações (por exemplo, comunicação geral)

Além disso, se encontrarmos algo quebrado / não funcionando corretamente com 4.3.1 (por exemplo, @georgiosd 's find acima ), devemos mencioná-lo aqui para conscientização, mas levar os detalhes em questões separadas para facilitar a discussão / acompanhamento.

Obrigado @karelz (e equipe MS). Vou continuar inscrito neste tópico então. 👍

Continue lutando o bom combate, time! 💯

Eu também tenho que agradecer a @ chadwackerman2

Parabéns a todos mais uma vez por resolver um dos bugs mais irritantes da história do .NET :)

@karelz feliz em fazer isso, mas me pergunto se esse é de alguma forma o comportamento esperado.

@georgiosd Eu não sei - será mais fácil discutir isso em uma questão separada ;-) (incluindo os especialistas certos)

Obrigado por conduzir este trabalho, @karelz

Eu sei que estou atrasado com a autópsia aqui, minhas desculpas.
Não esqueci, só não entendi ainda devido a prioridades mais altas (planejamento / rastreamento 2.0, olhando mais a fundo no problema de redirecionamentos de vinculação que surgiu aqui - dotnet / runtime # 17770)
Vou me esforçar para terminar a autópsia nas próximas 1-2 semanas.

Olá, Parabéns a todos os envolvidos na resolução deste problema. Não posso dizer que entendo todas as porcas e parafusos, mas uma coisa que ainda não entendo é por que isso só aconteceu quando atualizamos nossa solução do VS 2015 Atualização 3 para o VS 2017. A solução em questão era um conjunto de projetos ASP.Net Core visando a estrutura .net 4.6. O problema estava sendo acionado por nosso uso do Azure KeyVaultClient.

Obrigado donal

Olá, @karelz , tenho pesquisado e trabalhado duas noites seguidas até agora, mas não consigo consertar isso. Todos os meus pacotes System.Net.Http foram atualizados para a versão 4.3.1, mas ainda recebem o mesmo erro. Por favor me ajude, não sei mais o que tentar ou aonde ir. Obrigado!

FileNotFoundException: Não foi possível carregar o arquivo ou assembly 'System.Net.Http, Version = 4.1.1.0, Culture = neutral, PublicKeyToken = b03f5f7f11d50a3a'. O sistema não pode encontrar o arquivo especificado.

Um aqui meu .csproj

netcoreapp1.1

$ (PackageTargetFallback); portable-net45 + win8 + wp8 + wpa81;

aspnet-IbmVcaCore-5aa05652-04e7-4a42-9fd6-8dbc1c8b98fe

@parismiguel lamento saber disso :(. Você tem bindingRedirects de 4.0.0.0 a 4.1.1.0 em seu aplicativo?

<dependentAssembly> 
    <assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" /> 
    <bindingRedirect oldVersion="0.0.0.0-4.1.1.0" newVersion="4.1.1.0" /> 
</dependentAssembly> 

Estamos estudando como tornar a história de bindingRedirects mais suave: https://github.com/dotnet/corefx/issues/9846#issuecomment -287941109

ATUALIZAÇÃO: Olhando para o seu erro, parece que o problema é que sua versão 4.1.1.0 não foi encontrada. Você pode verificar o diretório do aplicativo se a versão correta do assembly está realmente lá?

@karelz foi rápido, muito obrigado! Eu vi o material bindingRedirects em posts anteriores, mas não tenho certeza de onde colocá-lo ... Eu tentei dentro do meu .csproj, mas encontrei erros (anexados como .txt) relativos à versão 4.1.1.0 I ' Não tenho certeza de seguir ... Não devo atualizá-lo para 4.3.1?

IbmVcaCore.csproj.txt

Os redirecionamentos de vinculação vão para o arquivo app.config ou web.config:

Veja isto para detalhes:
https://msdn.microsoft.com/en-us/library/7wd6ex19 (v = vs.110) .aspx

Oi @davidsh , obrigado pela ajuda!
Meu projeto não tem nenhum desses arquivos ... é uma construção de projeto NET Core usando o modelo Visul Studio 2017 ... o que estou perdendo?

Re: 4.3.1 vs. 4.1.1 - 4.3.1 é a versão do pacote NuGet, 4.1.1.0 é a versão do assembly (ildasm / ILSpy / VS irá mostrar para você).
As versões NuGet vs. assembly são um pouco confusas e é difícil conectar qual pertence a qual. Está na minha lista de coisas para examinarmos mais profundamente se pudermos conectar os pontos por meio da documentação (por exemplo, na página do NuGet).

Se você estiver no .NET Core, não precisa dos bindingRedirects e, além disso, esse problema NÃO o afeta de forma alguma. Este problema é específico do Desktop (= .NET Framework).
O pacote 4.3.1 NuGet modificou apenas seu assembly Desktop, não o assembly .NET Core.

Se você ainda tiver problemas, registre um novo bug e marque-me lá. Esse problema foi espalhado para muitas pessoas (já que foi impactante), seu problema não está relacionado a ele (pelo menos é o que parece), então vamos ser gentis com as notificações / caixas de entrada do GH de todos.

Para todos : Eu criei um novo problema dotnet / corefx # 17522 para rastrear o post-mortem que prometi.
Infelizmente, eu não fiz muito progresso nesse sentido :( ... mas pelo menos todos os interessados ​​podem começar a acompanhar essa questão e evitar ruídos potenciais sobre ela (tentando ajudar as pessoas a se concentrarem no que estão interessadas).

@karelz obrigado, vou seguir suas instruções e postar em seu novo rastreador de problemas. Saudações.

@parismiguel não é sobre o novo problema que criei, crie um novo. O que criei (# 17522) é para análise post-mortem porque esse problema (# 11100) demorou tanto para ser resolvido.

obrigado @karelz e minhas sinceras desculpas por bagunçar este tópico .... espero obter alguma ajuda no novo como instruído. Atenciosamente,

Parece que encontrei isso por meio de uma tempestade perfeita.

Estou usando a visualização do Azure Functions com uma combinação do Azure Key Vault (2.0.6) e do Octopus Client (4.15.3).

Eu tentei atualizar para System.Net.Http para 4.3.2 mas ainda falha ao tentar usar Key Vault .

Alguma dica?

@karelz

Você pode ter certeza de que o assembly do pacote nuget 4.3.2 é realmente usado em tempo de execução? (foi corrigido em 4.3.1)