Execução de lado a lado no processo
Começando com o .NET Framework versão 4, você pode usar no processo pelo lado de hospedagem para executar várias versões do que o common language runtime (CLR) em um único processo. Por padrão, gerenciado executados com os componentes COM o.NET Framework versão fossem construído com, independentemente da.NET Framework versão é carregado para o processo.
Segundo plano
A.NET Framework sempre tem fornecido lado a lado de gerenciada de hospedagem de código de aplicativos, mas antes de .NET Framework 4, não forneceu essa funcionalidade para componentes gerenciados do COM. No passado, os componentes gerenciados do COM que foram carregados em um processo executado com a versão do runtime que já foi carregado ou com o mais recente instalado a versão do.NET Framework. Se esta versão não era compatível com o componente COM, o componente falhará.
O .NET Framework 4 fornece uma nova abordagem para hospedagem de lado a lado que garante o seguinte:
Instalando uma nova versão do.NET Framework não tem efeito em aplicativos existentes.
Aplicativos executados em relação a versão do.NET Framework que eles foram criados com. Não usam a nova versão do.NET Framework, a menos que expressamente instruídos a fazer isso. No entanto, é mais fácil para os aplicativos a transição para o uso de uma nova versão do.NET Framework.
Efeitos em usuários e desenvolvedores
Os usuários finais e administradores de sistema. Esses usuários agora podem ter a maior confiança que ao instalar uma nova versão do tempo de execução, independentemente ou com um aplicativo, ele não terá impacto em seus computadores. Aplicativos existentes continuarão a execução como faziam antes.
Os desenvolvedores de aplicativos. Hospedagem de lado a lado quase não tem efeito sobre os desenvolvedores de aplicativos. Por padrão, aplicativos sempre executar a versão do.NET Framework que elas foram criadas em; não foi alterado. No entanto, os desenvolvedores podem substituir esse comportamento e direcionar o aplicativo seja executado em uma versão mais recente do.NET Framework (consulte o cenário 2).
Os desenvolvedores de bibliotecas e os consumidores. Hospedagem de lado a lado não resolve os problemas de compatibilidade enfrentadas pelos desenvolvedores de biblioteca. Uma biblioteca que é carregada diretamente por um aplicativo - por meio de uma referência direta ou de um Assembly.Load call – continua a usar o tempo de execução da AppDomain ele é carregado no. Você deve testar suas bibliotecas contra todas as versões do.NET Framework que você deseja oferecer suporte. Se um aplicativo é compilado usando o .NET Framework 4 runtime mas não inclui uma biblioteca que foi criada com um tempo de execução anterior, essa biblioteca usará o .NET Framework 4 tempo de execução como bem. No entanto, se você tiver um aplicativo que foi criado com um tempo de execução anterior e uma biblioteca que foi criada usando o .NET Framework 4, você deve forçar o seu aplicativo para usar também o .NET Framework 4 (consulte cenário 3).
Gerenciado os desenvolvedores de componentes COM. No passado, COM os componentes gerenciados automaticamente executado usando a última versão do runtime instalado no computador. Agora você pode executar os componentes COM contra o tempo de execução que eles foram criados com a versão.
Como mostra a tabela a seguir, os componentes que foram criados com o.NET Framework versão 1.1 pode executar lado a lado com componentes da versão 4, mas não pode ser executado com os componentes da versão 2.0, 3.0 ou 3.5, porque não está disponível para essas versões lado a lado de hospedagem.
.NET Framework versão
1.1
2.0 - 3.5
4
1.1
Não aplicável.
Não
Sim
2.0 - 3.5
Não
Não aplicável.
Sim
4
Sim
Sim
Não aplicável.
Observação
.NET Framework versões 3.0 e 3.5 são construídas de forma incremental na versão 2.0 e não precisará executar lado a lado.Inerentemente são a mesma versão.
Cenários comuns de hospedagem de lado a lado
Cenário 1: Aplicativo nativo que usa os componentes COM criados com versões anteriores do.NET Framework.
.NET Framework versões instaladas: O .NET Framework 4 e todas as outras versões do.NET Framework usada por componentes do COM.
O que fazer: Nesse cenário, não faça nada. Os componentes COM serão executados com a versão do.NET Framework,. que eles foram registrados.
Cenário 2: Gerenciado de aplicativo criado com o .NET Framework 2.0 SP1 que você preferir executar com o .NET Framework versão 2.0, mas estão dispostos a ser executado na .NET Framework 4 se a versão 2.0 não está presente.
.NET Framework versões instaladas: Uma versão anterior do.NET Framework e o .NET Framework 4.
O que fazer: No o arquivo de configuração do aplicativo no diretório de aplicativo, use o <startup> elemento e o <supportedRuntime> elemento definida da seguinte maneira:
<configuration> <startup > <supportedRuntime version="v2.0.50727" /> <supportedRuntime version="v4.0" /> </startup> </configuration>Cenário 3: Aplicativo nativo que usa os componentes COM criados com versões anteriores do.NET Framework que você deseja executar com o .NET Framework 4.
.NET Framework versões instaladas: O .NET Framework 4.
O que fazer: No arquivo de configuração do aplicativo no diretório de aplicativo, use o <startup> elemento com o useLegacyV2RuntimeActivationPolicy atributo definido como true e o <supportedRuntime> elemento definido da seguinte maneira:
<configuration> <startup useLegacyV2RuntimeActivationPolicy="true"> <supportedRuntime version="v4.0" /> </startup> </configuration>
Exemplo
O exemplo a seguir demonstra um host COM não gerenciado que está executando um componente gerenciado usando a versão do.NET Framework que o componente foi compilado para usar.
Para executar o exemplo a seguir, compilar e registrar o seguinte gerenciados COM o componente usando o .NET Framework versão 3.5. Para registrar o componente, o projeto menu, clique em Propriedades, clique o Construir guia e, em seguida, selecione o Register for COM interop caixa de seleção.
using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Runtime.InteropServices;
namespace BasicComObject
{
[ComVisible(true), Guid("9C99C4B5-CA54-4c58-8988-49B6811BA53B")]
public class MyObject : SimpleObjectModel.IPrintInfo
{
public MyObject()
{
}
public void PrintInfo()
{
Console.WriteLine("MyObject was activated in {0} runtime in:\n\tAppDomain {1}:{2}", System.Runtime.InteropServices.RuntimeEnvironment.GetSystemVersion(), AppDomain.CurrentDomain.Id, AppDomain.CurrentDomain.FriendlyName);
}
}
}
Compile o seguinte aplicativo de C++ não gerenciado, que ativa o objeto COM criada pelo exemplo anterior.
#include "stdafx.h"
#include <string>
#include <iostream>
#include <objbase.h>
#include <string.h>
#include <process.h>
using namespace std;
int _tmain(int argc, _TCHAR* argv[])
{
char input;
CoInitialize(NULL) ;
CLSID clsid;
HRESULT hr;
HRESULT clsidhr = CLSIDFromString(L"{9C99C4B5-CA54-4c58-8988-49B6811BA53B}",&clsid);
hr = -1;
if (FAILED(clsidhr))
{
printf("Failed to construct CLSID from String\n");
}
UUID id = __uuidof(IUnknown);
IUnknown * pUnk = NULL;
hr = ::CoCreateInstance(clsid,NULL,CLSCTX_INPROC_SERVER,id,(void **) &pUnk);
if (FAILED(hr))
{
printf("Failed CoCreateInstance\n");
}else
{
pUnk->AddRef();
printf("Succeeded\n");
}
DISPID dispid;
IDispatch* pPrintInfo;
pUnk->QueryInterface(IID_IDispatch, (void**)&pPrintInfo);
OLECHAR FAR* szMethod[1];
szMethod[0]=OLESTR("PrintInfo");
hr = pPrintInfo->GetIDsOfNames(IID_NULL,szMethod, 1, LOCALE_SYSTEM_DEFAULT, &dispid);
DISPPARAMS dispparams;
dispparams.cNamedArgs = 0;
dispparams.cArgs = 0;
VARIANTARG* pvarg = NULL;
EXCEPINFO * pexcepinfo = NULL;
WORD wFlags = DISPATCH_METHOD ;
;
LPVARIANT pvRet = NULL;
UINT * pnArgErr = NULL;
hr = pPrintInfo->Invoke(dispid,IID_NULL, LOCALE_USER_DEFAULT, wFlags,
&dispparams, pvRet, pexcepinfo, pnArgErr);
printf("Press Enter to exit");
scanf_s("%c",&input);
CoUninitialize();
return 0;
}
Consulte também
Referência
Histórico de alterações
Date |
History |
Motivo |
|---|---|---|
|
Agosto de 2010 |
Corrigido o número de versão.NET Framework 2.0 no arquivo de configuração do aplicativo. |
Comentários do cliente. |