Compartilhar via

.NET Framework 4.5 é padrão e .NET Framework 3.5 é opcional

Plataformas

Clientes – servidores Windows 8 – Windows Server 2012

Descrição

.NET Framework 4.5 está habilitado por padrão no Windows 8. Windows 8 não inclui o .NET 3.5 por padrão, mas os arquivos do .NET 3.5 estão disponíveis na mídia de instalação Windows 8 como um recurso opcional.

Se o usuário estiver atualizando do Windows 7 para Windows 8, o .NET Framework 3.5 estará totalmente habilitado para garantir que todos os aplicativos no computador continuem funcionando corretamente.

Manifestação

Se o usuário executar uma instalação limpa de Windows 8 e instalar aplicativos que exigem .NET Framework 3.5 (ou 2.0), ele disparará uma solicitação para os arquivos .NET 3.5 necessários. Normalmente, os arquivos ausentes serão baixados do Windows Update (depois de pedir permissão ao usuário), mas se o acesso ao Windows Update não for possível, a habilitação .NET Framework 3.5 falhará, a menos que uma fonte alternativa para os arquivos ausentes tenha sido especificada.

Atenuação

Para habilitar .NET Framework 3.5 somente em computadores de teste com instalações limpas de Windows 8:

  1. Copie \sources\sxs\ da imagem ISO de build do sistema operacional montada para dotnet35 ou pasta semelhante. Por exemplo:

    xcopy e:\sources\sxs\*.* c:\dotnet35 /s

  2. Execute esta linha de comando usando privilégios de administrador:

    Dism.exe /online /enable-feature /featurename:NetFX3 /All /Source:c:\dotnet35 /LimitAccess

Observação

A pasta sources\SxS não deve ser usada como um mecanismo de redistribuição, pois esse não é um mecanismo com suporte.

Solução

Para consumidores:

Windows 8 inclui um mecanismo que habilita automaticamente .NET Framework 3.5 ao tentar instalar o pacote redistribuível ou quando um instalador de aplicativo que precisa do .NET 3.5 invoca o redistribuível.

Para desenvolvedores de aplicativos (e administradores de TI):

Os administradores de TI podem configurar aplicativos .NET 3.5 para serem executados no .NET 3.5 ou no .NET 4.5 (dependendo do que já está instalado). Para executar um aplicativo gerenciado na versão 3.5 ou 4.5, basta adicionar uma seção no arquivo de configuração do aplicativo. Isso garantirá que, se o .NET 3.5 estiver instalado, o aplicativo será executado no .NET 3.5; caso contrário, o aplicativo será executado no .NET 4.5. Um exemplo da seção adicional no arquivo de configuração é fornecido abaixo:

<configuration>
   <startup>
      <supportedRuntime version="v2.0.50727"/>
      <supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5"/>
   </startup>
</configuration>

Para OEMs corporativos:

Para habilitar .NET Framework 3.5 para builds EEAP e para aplicativos que não têm acesso a Windows Update:

  1. Copie \sources\sxs\ da imagem ISO de build do sistema operacional montada para a pasta dotnet35 ou semelhante. Por exemplo:

    xcopy e:\sources\sxs\*.* c:\dotnet35 /s

  2. Defina a chave regkey:

    [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing]
“LocalSourcePath”=”c:\dotnet35”

Para empresas:

Para computadores configurados para usar o WSUS para manutenção, você pode definir uma entrada do Registro para permitir que o computador use Windows Update para habilitar o .NET 3.5 em vez do WSUS (a manutenção ainda será feita do WSUS se você fizer isso).

  • Defina a chave regkey:

    [HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\Servicing] “RepairContentServerSource”=DWORD(2)

Essa entrada do Registro também pode ser definida por meio de Política de Grupo (Política de Computador Local –> Configuração do Computador –> Modelos Administrativos –> Sistema. Selecione a configuração "Especificar configurações para instalação de componente opcional e reparo de componente".

Se você selecionar "Entrar em contato Windows Update diretamente para baixar o conteúdo de reparo em vez de Windows Server Update Services (WSUS)", qualquer tentativa de adicionar recursos do Windows (por exemplo, .NET Framework 3.5) ou reparar recursos disparará downloads de arquivos de Windows Update. Computadores de destino exigem acesso à Internet e WU para essa opção. As operações normais de manutenção continuarão a usar o WSUS se ele tiver sido configurado como uma origem.

Uma observação sobre como definir o local de origem local por meio de entradas do Registro

Os administradores de TI podem definir locais de origem locais para arquivos .NET 3.5 por meio de uma entrada do Registro, para que os usuários possam usar a caixa de diálogo Adicionar/Remover Recursos do Windows para habilitar recursos com conteúdo ausente sem precisar especificar um local de origem. O valor da entrada do Registro pode ser controlado por meio da política de grupo.

Essa entrada do Registro tem suporte:

Entrada Tipo Descrição
Caminho de origem local REG_EXPAND_SZ

Caminhos de origem locais a serem usados por padrão. Vários caminhos podem ser especificados; eles devem ser separados por ";". Os locais serão pesquisados na ordem em que forem especificados.

Locais de origem locais especificados na linha de comando DISM, têm precedência sobre os locais especificados nesta entrada do Registro. Os locais da pasta podem ser especificados nesta entrada do Registro.

WIMs podem ser usados, mas o caminho deve ser para o arquivo WIM; não há necessidade de montá-lo, por exemplo:

wim:\\machine\share\file.wim:1 Observe o "1" no final. Você deve especificar o índice numérico da imagem que deseja usar no arquivo WIM.

Para um WIM montado, o caminho de origem precisa se referir ao diretório do Windows da imagem montada, em vez do ponto de montagem (por exemplo: /source:<mount_point>\windows em vez de /source:<mount_point>).

Recursos

Implementando a política baseada em Registro