O Azure Data Lake Analytics está a atualizar para o .NET Framework v4.7.2

Importante

O Azure Data Lake Analytics descontinuado a 29 de fevereiro de 2024. Saiba mais com este anúncio.

Para análise de dados, a sua organização pode utilizar o Azure Synapse Analytics ou o Microsoft Fabric.

O runtime predefinido do Azure Data Lake Analytics está a ser atualizado de .NET Framework v4.5.2 para .NET Framework v4.7.2. Esta alteração apresenta um pequeno risco de interrupção de alterações se o código U-SQL utilizar assemblagens personalizadas e essas assemblagens personalizadas utilizarem bibliotecas .NET.

Esta atualização do .NET Framework 4.5.2 para a versão 4.7.2 significa que o .NET Framework implementado num runtime U-SQL (o runtime predefinido) será sempre 4.7.2. Não existe uma opção lado a lado para .NET Framework versões.

Após a conclusão desta atualização para o .NET Framework 4.7.2, o código gerido do sistema será executado como versão 4.7.2. As bibliotecas fornecidas pelo utilizador, como as assemblagens personalizadas U-SQL, serão executadas no modo retrocompatível adequado à versão para a qual a assemblagem foi gerada.

• Se os DLLs de assemblagem forem gerados para a versão 4.5.2, a arquitetura implementada irá tratá-los como bibliotecas 4.5.2, fornecendo (com algumas exceções) semântica 4.5.2.
• Agora, pode utilizar assemblagens personalizadas U-SQL que utilizam as funcionalidades da versão 4.7.2, se segmentar o .NET Framework 4.7.2.

Devido a esta atualização para o .NET Framework 4.7.2, existe um potencial para introduzir alterações interruptivas nas tarefas U-SQL que utilizam assemblagens personalizadas .NET. Sugerimos que verifique se existem problemas de retrocompatibilidade com o procedimento abaixo.

Como verificar se existem problemas de retrocompatibilidade

Verifique se existem potenciais problemas de quebra de retrocompatibilidade ao executar as verificações de compatibilidade .NET no código .NET nas assemblagens personalizadas U-SQL.

Nota

A ferramenta não deteta alterações interruptivas reais. identifica apenas as chamadas APIs .NET que podem (para determinadas entradas) causar problemas. Se receber uma notificação de um problema, o código poderá continuar a estar em bom estado. No entanto, deve verificar mais detalhes.

1. Execute o verificador de retrocompatibilidade nas DLLs .NET através de
   1. Utilizar a Extensão do Visual Studio na Extensão do Visual Studio .NET Portability Analyzer
   2. Transferir e utilizar a ferramenta autónoma do GitHub dotnetapiport. As instruções para executar a ferramenta autónoma estão em Alterações interruptivas do dotnetapiport do GitHub
   3. Para 4.7.2. compatibilidade, read isRetargeting == True identifica possíveis problemas.
2. Se a ferramenta indicar se o código pode ser afetado por qualquer uma das possíveis incompatibilidades anteriores (alguns exemplos comuns de incompatibilidades estão listados abaixo), pode verificar mais detalhadamente
   1. Analisar o código e identificar se o código está a transmitir valores para as APIs afetadas
   2. Efetue uma verificação de runtime. A implementação do runtime não é efetuada lado a lado no ADLA. Pode efetuar uma verificação de runtime antes da atualização, utilizando a execução local do VisualStudio com um .NET Framework 4.7.2 local num conjunto de dados representativo.
3. Se, de facto, for afetado por uma incompatibilidade retroativa, siga os passos necessários para corrigi-la (como corrigir os dados ou a lógica de código).

Na maioria dos casos, não deve ser afetado pela incompatibilidade retroativa.

Linha cronológica

Pode verificar a implementação do novo runtime aqui Resolução de problemas do Runtime e ao analisar qualquer tarefa com êxito anterior.

E se não conseguir rever o meu código a tempo

Pode submeter a sua tarefa em relação à versão de runtime antiga (criada com o objetivo 4.5.2), no entanto, devido à falta de .NET Framework capacidades lado a lado, esta continuará a ser executada apenas no modo de compatibilidade 4.5.2. Ainda poderá encontrar alguns dos problemas de retrocompatibilidade devido a este comportamento.

Quais são os problemas de retrocompatibilidade mais comuns que pode encontrar

As incompatibilidades retroativas mais comuns que é provável que o verificador identifique são (gerámos esta lista ao executar o verificador nas nossas próprias tarefas internas do ADLA), que as bibliotecas são afetadas (nota: pode chamar as bibliotecas apenas indiretamente, pelo que é importante tomar as medidas necessárias n.º 1 para verificar se as suas tarefas são afetadas) e possíveis ações para remediar. Nota: Em quase todos os casos para os nossos próprios trabalhos, os avisos revelaram-se falsos positivos devido às naturezas estreitas da maioria das alterações interruptivas.

• A propriedade IAsyncResult.CompletedSynchronously tem de estar correta para a tarefa resultante ser concluída

  • Ao chamar TaskFactory.FromAsync, a implementação da propriedade IAsyncResult.CompletedSynchronously tem de estar correta para a tarefa resultante ser concluída. Ou seja, a propriedade tem de devolver verdadeiro se, e apenas se, a implementação for concluída de forma síncrona. Anteriormente, a propriedade não estava selecionada.
  • Bibliotecas Afetadas: mscorlib, System.Threading.Tasks
  • Ação Sugerida: Garantir que TaskFactory.FromAsync devolve verdadeiro corretamente

• DataObject.GetData obtém agora dados como UTF-8

  • Para aplicações que visam o .NET Framework 4 ou que são executadas no .NET Framework 4.5.1 ou versões anteriores, DataObject.GetData obtém dados formatados em HTML como uma cadeia ASCII. Como resultado, os carateres não ASCII (carateres cujos códigos ASCII são maiores do que 0x7F) são representados por dois carateres aleatórios.#N##N#For aplicações que visam o .NET Framework 4.5 ou posterior e são executados no .NET Framework 4.5.2, DataObject.GetData obtém dados formatados em HTML como UTF-8, que representa carateres maiores do que 0x7F corretamente.
  • Bibliotecas Afetadas: Glo
  • Ação Sugerida: certifique-se de que os dados obtidos são o formato pretendido

• XmlWriter lança em pares de substituição inválidos

  • Para aplicações que visam o .NET Framework 4.5.2 ou versões anteriores, escrever um par de substituição inválido utilizando o processamento de contingência de exceções nem sempre gera uma exceção. Para aplicações que visam o .NET Framework 4.6, tentar escrever um par de substituição inválido gera um ArgumentException.
  • Bibliotecas Afetadas: System.Xml, System.Xml. Leitor de Leitura
  • Ação Sugerida: certifique-se de que não está a escrever um par de substituição inválido que causará uma exceção de argumento

• HtmlTextWriter não compõe <br/> o elemento corretamente

  • A partir do .NET Framework 4.6, chamar HtmlTextWriter.RenderBeginTag() e com um <BR /> elemento irá inserir corretamente apenas um <BR /> (em HtmlTextWriter.RenderEndTag() vez de dois)
  • Bibliotecas Afetadas: System.Web
  • Ação Sugerida: certifique-se de que está a inserir a quantidade de <BR /> que espera ver para que não seja visto qualquer comportamento aleatório na tarefa de produção

• A chamada CreateDefaultAuthorizationContext com um argumento nulo foi alterada

  • A implementação do AuthorizationContext devolvida por uma chamada para o CreateDefaultAuthorizationContext(IList<IAuthorizationPolicy>) com um argumento authorizationPolicies nulo alterou a sua implementação no .NET Framework 4.6.
  • Bibliotecas Afetadas: System.IdentityModel
  • Ação Sugerida: certifique-se de que está a lidar com o novo comportamento esperado quando existe uma política de autorização nula

• O RSACng carrega agora corretamente chaves RSA de tamanho de chave não padrão

  • No .NET Framework versões anteriores à versão 4.6.2, os clientes com tamanhos de chave não padrão para certificados RSA não conseguem aceder a essas chaves através dos GetRSAPublicKey() métodos e GetRSAPrivateKey() da extensão. É CryptographicException emitida uma mensagem com a mensagem "O tamanho da chave pedida não é suportado". Com a .NET Framework 4.6.2, este problema foi corrigido. Da mesma forma, RSA.ImportParameters() e RSACng.ImportParameters() agora trabalha com tamanhos de chave não padrão sem atirar CryptographicException"s".
  • Bibliotecas Afetadas: mscorlib, System.Core
  • Ação Sugerida: Certifique-se de que as chaves RSA estão a funcionar conforme esperado

• As verificações de dois pontos de caminho são mais rigorosas

  • No .NET Framework 4.6.2, foram efetuadas muitas alterações para suportar caminhos anteriormente não suportados (tanto no comprimento como no formato). As verificações da sintaxe do separador de unidade (dois pontos) adequada foram mais corretas, o que teve o efeito colateral de bloquear alguns caminhos de URI em algumas APIs de Caminho selecionadas onde costumavam ser toleradas.
  • Bibliotecas Afetadas: mscorlib, System.Runtime.Extensions
  • Ação Sugerida:

• Chamadas para construtores ClaimsIdentity

  • A partir do .NET Framework 4.6.2, há uma alteração na forma como T:System.Security.Claims.ClaimsIdentity os construtores com um T:System.Security.Principal.IIdentity parâmetro definem a P:System.Security.Claims.ClaimsIdentify.Actor propriedade. Se o T:System.Security.Principal.IIdentity argumento for um T:System.Security.Claims.ClaimsIdentity objeto e a P:System.Security.Claims.ClaimsIdentify.Actor propriedade desse T:System.Security.Claims.ClaimsIdentity objeto não nullfor , a P:System.Security.Claims.ClaimsIdentify.Actor propriedade é anexada através do M:System.Security.Claims.ClaimsIdentity.Clone método . No Framework 4.6.1 e versões anteriores, a P:System.Security.Claims.ClaimsIdentify.Actor propriedade é anexada como uma referência existente. Devido a esta alteração, começando pela .NET Framework 4.6.2, a P:System.Security.Claims.ClaimsIdentify.Actor propriedade do novo T:System.Security.Claims.ClaimsIdentity objeto não é igual à P:System.Security.Claims.ClaimsIdentify.Actor propriedade do argumento do T:System.Security.Principal.IIdentity construtor. No .NET Framework 4.6.1 e versões anteriores, é igual.
  • Bibliotecas Afetadas: mscorlib
  • Ação Sugerida: Certifique-se de que ClaimsIdentity está a funcionar conforme esperado no novo runtime

• A serialização de carateres de controlo com DataContractJsonSerializer é agora compatível com ECMAScript V6 e V8

  • No .NET Framework 4.6.2 e versões anteriores, o DataContractJsonSerializer não serializou alguns carateres de controlo especiais, como \b, \f e \t, de uma forma compatível com as normas ECMAScript V6 e V8. A partir do .NET Framework 4.7, a serialização destes carateres de controlo é compatível com eCMAScript V6 e V8.
  • Bibliotecas Afetadas: System.Runtime.Serialization.Json
  • Ação Sugerida: Garantir o mesmo comportamento com DataContractJsonSerializer