Alterações no .NET Framework 3.5 SP1

Este documento descreve as alterações de design que podem precisar ser contabilizados em seu aplicativo ou ambiente quando você atualiza do .NET Framework versão 3.5 para .NET Framework versão 3.5 Service Pack 1 (SP1).

As alterações ocorrem por vários motivos, incluindo correções para problemas de produto, conformidade de padrões, comentários do cliente e segurança. Este tópico descreve apenas alterações importantes. Para obter informações sobre novos recursos, consulte Novidades no .NET Framework . Para fornecer comentários, visite o Centro de Comentários sobre Produtos do MSDN.

As seções a seguir descrevem as alterações feitas no .NET Framework versão 3.5 SP1.

Common Language Runtime

Melhorias de desempenho Os aplicativos agora usam a Prevenção de Execução de Dados para evitar tentativas de inserir e executar código de locais de memória não executáveis. A segurança para execução de código gerenciado (incluindo assemblies MSIL, imagens NGen e código não gerenciado) é reforçada pelo ASLR (Address Space Layout Randomization). Assemblies fortemente nomeados e assinados não precisam mais ter suas assinaturas verificadas em tempo de carga, desde que sejam totalmente confiáveis e sejam carregados em domínios de aplicativo totalmente confiáveis. Essa alteração elimina verificações redundantes e melhora o desempenho de inicialização de aplicativos que têm assemblies assinados, mas não estão instalados no GAC (Cache de Assembly Global). Os aplicativos iniciados a partir de compartilhamentos de rede têm o mesmo comportamento que executáveis não gerenciados e operam em confiança total em vez de confiança parcial. O atributo StringFreezingAttribute agora é ignorado. Esse atributo foi usado para criar imagens nativas usando o Gerador de Imagem Nativa (Ngen.exe). O compilador JIT (Just-In-Time) foi aprimorado significativamente para gerar um código de melhor qualidade. No entanto, alterar o embutido tem um impacto nos aplicativos que têm classes instanciadas com construtores que usam o valor de enumeração TypeAttributes.BeforeFieldInit. É garantido que a inicialização estática desses tipos ocorra em um momento antes que qualquer um dos campos estáticos seja acessado, mas não antes que um método estático ou construtor de instância seja invocado. A hora exata em que o construtor de classe é invocado pode ser diferente no .NET Framework versão 3.5 e 3.5 SP1. Outras alterações do compilador JIT incluem alterações em erros de arredondamento de ponto flutuante e alterações no tempo dos finalizadores. Nenhuma modificação é necessária.

ADO.NET

Métodos CanConvertToString em classes value serializer Os métodos CanConvertToString nas classes de serializador de valor no namespace System.Windows.Converters geram uma ArgumentException em vez de retornar false. Os métodos System.Data.SqlClient.SQLDataReader.GetString e oth er Get lançarão um InvalidCastException se os dados não puderem ser convertidos no tipo que está sendo solicitado. As mensagens agora incluem os tipos, como: "Não é possível converter o objeto do tipo 'System.Decimal' para digitar 'System.String'". Nenhuma modificação é necessária.

SQLDataReader.GetString em colunas UDT Chamar o método SQLDataReader.GetString em colunas de Tipo Definido pelo Usuário (UDT) agora lança uma InvalidCastException em vez da mensagem de erro "A conversão não tem suporte de Byte[] para String". Nenhuma modificação é necessária.

C#

As consultas em coleções não genéricas agora usam semântica de conversão padrão do C#. Em expressões de consulta LINQ em coleções não genéricas, como System.Collections.ArrayList , a cláusula from da consulta é reescrita pelo compilador para incluir uma chamada para o operador Cast<T> . Cast<T> converte todos os tipos de elemento para o tipo especificado na cláusula from na consulta. Além disso, na versão de versão original do Visual C# 2008, o operador Cast<T> também executa algumas conversões de tipo de valor e conversões definidas pelo usuário. No entanto, essas conversões são executadas usando a classe System.Convert em vez da semântica padrão do C#. Essas conversões também causam problemas significativos de desempenho em determinados cenários. No Visual C# 2008 SP1, o operador Cast<T> é modificado para gerar um InvalidCastException para o tipo de valor numérico e conversões definidas pelo usuário. Essa alteração elimina a semântica de conversão C# não padrão e o problema de desempenho. Essa alteração é ilustrada no exemplo a seguir. using System; using System.Linq; class Program {     public struct S { }     static void Main()     {         var floats = new float[] { 2.7f, 3.1f, 4.5f };         var ints = from int i in floats                    select i;         // Visual C# 2008 SP1 throws InvalidCastException.         foreach (var v in ints)             Console.Write("{0} ", v.ToString());         // The original release version of Visual C# 2008         // compiles and outputs 3 3 4     } } Modificações sugeridas: se você tiver um código que executa consultas LINQ em coleções não genéricas e esse código agora gerar uma exceção, altere o tipo da expressão de consulta para corresponder ao tipo dos elementos na coleção que você está consultando. Se você precisar executar um tipo de valor ou conversão definida pelo usuário nos elementos, poderá fazer isso enquanto executa a consulta, conforme mostrado no exemplo a seguir: using System; using System.Linq; class Program {     static void Main(string[] args)     {         ArrayList floats = new ArrayList();         floats.Add(2.7f);         floats.Add(3.1f);         floats.Add(4.5f);         var query = from float f in floats                     where f > 3.0f                     select f;         foreach (int i in floats)         {             // Perform the conversion as you             // execute the query.             int num = Convert.ToInt32(i);             Console.Write("{0} ", num.ToString());         }         Console.ReadLine(); // output is 3 4     } }

ASP.NET, IIS

Modo Integrado do IIS No modo de integração dos Serviços de Informações da Internet (IIS) 7.0, o método HttpServerUtility.TransferRequest usa incorretamente o método HTTPResponse.End para interromper a solicitação pai. Isso resulta na criação de um ThreadAbortException , que pode afetar o desempenho para encerrar a execução de uma resposta. No .NET Framework 3.5 SP1, o método TransferRequest agora encerra a solicitação pai usando o método HttpApplication.CompleteRequest. Isso também encerra a solicitação atual normalmente transferindo o controle para o manipulador de eventos HttpApplication.EndRequest sem gerar uma exceção. Modificações sugeridas: se você tiver um código de tratamento de erros que usa o método TransferRequest para determinar se o ThreadAbortException foi lançado, você poderá remover esse código do bloco catch. (Por fim, os blocos continuarão a ser executados.)

Autenticação integrada do Windows Uma alteração de segurança afeta a forma como a autenticação do Windows integrada é tratada pelo System.Net.HttpWebRequest , System.Net.HttpListener , System.Net.Security.NegotiateStream e classes relacionadas no namespace System.Net. Essa alteração pode afetar servidores Web e aplicativos cliente configurados para usar autenticação do Windows integrados. O processo de autenticação NTLM (Microsoft Windows NT LAN Manager) usado com autenticação do Windows integrado inclui um desafio emitido pelo computador de destino que é enviado de volta para o computador cliente. Quando um computador recebe um desafio gerado, a autenticação falhará a menos que a conexão seja uma conexão de loop back (por exemplo, endereço IPv4 127.0.0.1). A classe HttpWebRequest agora usa como padrão especificar o nome do host usado na URL de solicitação no SPN (Nome da Entidade de Serviço) usado no processo de autenticação NTLM. Modificações Sugeridas: você pode fornecer um SPN personalizado para usar durante a autenticação em um dicionário de cadeias de caracteres indexadas pelo URI. Esse dicionário é obtido com a propriedade System.Net.AuthenticationManager.CustomTargetNameDictionary. Você também pode adicionar a seguinte configuração do Registro para mapear nomes para a conexão de loop back: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\MSV1_0\BackConnectionHostNames

CDOSYS As classes no namespace System.Web.Mail dependem de Objetos de Dados de Colaboração para componentes do Windows 2000, que não estarão disponíveis na próxima versão do Windows (Windows 7). Como resultado, o uso dessas classes no Windows 7 lançará uma PlatformNotSupportedException . Modificações sugeridas: System.Web.Mail foi preterido no .NET Framework versão 2.0. Em vez disso, use o suporte de email no namespace System.Net.Mail.

ASP.NET validações de solicitação ASP.NET validação de solicitação agora inclui verificar o colchete angular esquerdo e a sequência de caracteres de ponto de interrogação: <? Modificações de suggested: o impacto dessa alteração deve ser mínimo porque geralmente não há motivo para que um comentário XML seja incluído na cadeia de caracteres de consulta da variável de cookie.

Validações de URL ASP.NET agora valida partes da URL quando acessadas de uma página de ASP.NET. No entanto, quando a reescrita de URL é usada, é possível acessar a versão antiga da URL na página com a propriedade Request.RawUrl. Modificações sugeridas: desabilite a validação em uma página, se necessário.

Estados de sessão Espera-se que os provedores de estado de sessão implementem todos os membros definidos na classe System.Web.SessionState.SessionStateStoreProviderBase, incluindo o método CreateUninitializedItem. No entanto, esse método foi chamado somente quando um estado de sessão sem cookie estava em uso pelo site. Os desenvolvedores que não usaram um estado de sessão sem cookie não precisaram implementar CreateUninitializedItem em um provedor personalizado. Com o lançamento do .NET Framework 3.5 SP1, o método CreateUninitializedItem agora também pode ser chamado em determinadas circunstâncias quando um estado de sessão com cookie está sendo usado. Modificações sugeridas: implemente CreateUninitializedItem em provedores personalizados. Determine se já existe um item "dinâmico" para a ID de sessão especificada. Se um item não existir, os provedores deverão criar um item para a ID da sessão.

Codificação de URL ASP.NET agora expande a codificação de URL de cabeçalhos HTTP de saída para incluir o caractere de exclusão (7F) e todos os caracteres de controle ASCII (exceto a guia horizontal). Modificações sugeridas: se necessário, você pode desativar o comportamento de codificação de cabeçalho padrão da seguinte maneira: <httpRuntime enableHeaderChecking="true|false" />

DefaultHTTPHandler no IIS Embora a classe System.Web.DefaultHTTPHandler para aplicativos de modo integrado tenha se tornado um módulo obsoleto no IIS 7.0, ainda era possível usar. Agora, ele gera uma exceção PlatformNotSupported . Modificações Sugeridas: altere a configuração do aplicativo para funcionar corretamente no modo integrado.

Consistências de formatação de número de servidor e cliente O comportamento de formatação da função Number.localeFormat (executado no cliente) agora está em conformidade com o método String.Format (executado no servidor). Por exemplo, o código a seguir retorna 1000.00% : String.Format("{0:p2}", 10) Antes de .NET Framework 3.5 SP1, o seguinte código retornaria 10.00% : String.localeFormat("{0:p2}", 10) Agora, localeFormat retorna 1000.00% . Nenhuma modificação é necessária.

ASP.NET campos ocultos Campos de ASP.NET ocultos, como VIEWSTATE, agora são renderizados na parte superior do <form /> antes de renderizar quaisquer controles. Modificações sugeridas: eu f necessário, você pode desativar esse comportamento definindo o novo atributo renderAllHiddenFieldsAtTopOfForm como false:   <pages renderAllHiddenFieldsAtTopOfForm="false" /> O valor padrão é true.

Windows Presentation Foundation (WPF)

As classes BitmapEffect são obsoletas A classe System.Windows.Media.Effects.BitmapEffect e suas classes derivadas (BevelBitmapEffect, BitmapEffectGroup, BlurBitmapEffect, DropShadowBitmapEffect, EmbossBitmapEffect e OuterGlowBitmapEffect) agora estão obsoletas. Modificações sugeridas: descontinue o uso do BitmapEffect herdado e das classes derivadas e, em vez disso, use as novas classes derivadas de Effect:BlurEffect, DropShadowEffect e ShaderEffect.  Você também pode criar seus próprios efeitos derivando de ShaderEffect.

Alteração do nome do assembly O assembly que contém a camada de renderização principal do WPF foi renomeado de milcore.dll para wpfgfx_v0300.dll. Este assembly nunca teve APIs públicas. Nenhuma modificação é necessária.

Comportamento do hiperlink Se o valor da propriedade Hyperlink.NavigateUri mudar entre a hora em que o usuário passar o cursor do mouse sobre um hiperlink e a hora em que o usuário clicar nesse hiperlink, a navegação ocorrerá usando o URI obtido quando o cursor passar o mouse sobre o hiperlink. Nenhuma modificação é necessária.

Internet Explorer no Modo Protegido no Windows Vista Quando o Explorer da Internet está no Modo Protegido no Windows Vista, as caixas de diálogo modais da função de alerta DHTML () e os controles ActiveX hospedados em HTML são bloqueados em vez de exibidos. Além disso, quando o controle WebBrowser ou o controle Frame que hospeda o HTML está em um XBAP (Aplicativo do Navegador XMAL) e o XBAP é carregado entre domínios em uma página HTML, uma exceção é gerada. Nenhuma modificação é necessária.

Métodos CanConvertToString em classes value serializer Os métodos CanConvertToString nas classes de serializador de valor nos namespaces System.Windows.Media.Converters e System.Windows.Media.Media3D.Converters geram uma ArgumentException em vez de retornar false. Nenhuma modificação é necessária.

Windows Communication Foundation (WCF) e Windows Workflow Foundation (WF)

Correspondência de esquema O esquema de correspondência de esquema usado pelas classes UriTemplate e UriTemplateTable foi relaxado para aceitar endereços base com esquemas diferentes de HTTP. Agora, nenhuma dessas classes usa o esquema ou o número da porta ao corresponder URIs candidatos a modelos. O suporte de modelo para barras à direita e valores padrão foi adicionado. Nenhuma modificação é necessária.

Melhorias de segurança para autenticação Quando um serviço está em execução em uma conta de usuário com segurança de modo misto, uma EndPointIdentity deve ter uma identidade UPN (nome de entidade de usuário). Isso não era necessário com versões anteriores do WCF. Modificações sugeridas: quando um cliente é definido para usar a configuração SecurityMode.TransportWithMessageCredential (usando autenticação do Windows, autenticação UPN ou autenticação de impressão digital), crie uma instância da classe EndPointAddress com uma identidade UPN e forneça código personalizado para manipular qualquer verificação de impressão digital.

Suporte de confiança parcial para registro em log de eventos A confiança parcial agora dá suporte ao registro em log de eventos limitado. Somente falhas de ativação de serviço, falhas de rastreamento e falhas de log são registradas no Log de Eventos. Para evitar gravar mensagens excessivas no Log de Eventos, o número máximo de eventos que podem ser registrados por um processo é 5. Nenhuma modificação é necessária.

Disponibilidade de RemoteEndpointMessageProperty Acessar uma instância da classe RemoteEndpointMessageProperty ao usar HTTP hospedado no IIS depende de ter uma solicitação ativa no momento.  Portanto, ela não pode ser obtida após a conclusão da solicitação (por exemplo, ao executar um recebimento unidirecional). Nenhuma modificação é necessária.

Nota: Para resolver problemas de interrupção tardia que foram essenciais para alguns aplicativos, a Microsoft planeja fornecer uma atualização para o NET Framework 3.5 SP1 que pode ser incluída em uma Windows Update importante. Mais informações sobre essa atualização estarão disponíveis na página de download do .NET Framework 3.5 SP1 no Centro de Download da Microsoft.

Consulte Também

Versão do .NET Framework e informações de Assembly