O que ‘useLegacyV2RuntimeActivationPolicy’ faz na configuração do .NET 4?

Ao converter um projeto que usava SlimDX e, portanto, tem código não gerenciado, para o .NET 4.0, encontrei o seguinte erro:

A assembly de modo misto é construída contra a versão ‘v2.0.50727’ do tempo de execução e não pode ser carregada no tempo de execução 4.0 sem informações de configuração adicionais.

Googling me deu a solução, que é adicionar isso à configuração dos aplicativos:

     

Minha pergunta é: o que o useLegacyV2RuntimeActivationPolicy fazendo? Não consigo encontrar nenhuma documentação sobre isso.

Depois de um pouco de tempo (e mais pesquisas), encontrei este blog de Jomo Fisher.

Um dos problemas recentes que vimos é que, devido ao suporte para tempos de execução lado-a-lado, o .NET 4.0 mudou a maneira como ele se liga a assemblies de modo misto mais antigos. Esses assemblies são, por exemplo, aqueles que são compilados de C ++ \ CLI. Conjuntos DirectX atualmente disponíveis são modo misto. Se você vir uma mensagem como essa, saberá que se deparou com o problema:

A assembly de modo misto é construída contra a versão ‘v1.1.4322’ do tempo de execução e não pode ser carregada no tempo de execução 4.0 sem informações de configuração adicionais.

[Recorte]

A boa notícia para os aplicativos é que você tem a opção de voltar à vinculação de era do .NET 2.0 para esses assemblies definindo um sinalizador app.config da seguinte forma:

    

Portanto, parece que a maneira como o runtime carrega os assemblies de modo misto foi alterada. Não consigo encontrar detalhes sobre essa alteração ou por que isso foi feito. Mas o atributo useLegacyV2RuntimeActivationPolicy reverte para o carregamento do CLR 2.0.

Aqui está uma explicação que escrevi recentemente para ajudar com o vazio de informações sobre este atributo. http://www.marklio.com/marklio/PermaLink,guid,ecc34c3c-be44-4422-86b7-900900e451f9.aspx (link do Internet Archive Wayback Machine)

Para citar os bits mais relevantes:

[Instalando o .NET] v4 é “sem impacto”. Não deve alterar o comportamento dos componentes existentes quando instalado.

O atributo useLegacyV2RuntimeActivationPolicy basicamente permite dizer: “Eu tenho algumas dependencies nas APIs de correção legadas. Por favor, faça-os trabalhar como costumavam fazer com relação ao tempo de execução escolhido. ”

Por que não fazemos disso o comportamento padrão? Você pode argumentar que esse comportamento é mais compatível e torna o código de portabilidade de versões anteriores muito mais fácil. Se você se lembrar, esse não pode ser o comportamento padrão porque tornaria a instalação da versão 4 impactante, o que pode interromper os aplicativos existentes instalados na sua máquina.

O post completo explica isso com mais detalhes. No RTM, os documentos do MSDN sobre isso devem ser melhores.