Nota
O acesso a esta página requer autorização. Podes tentar iniciar sessão ou mudar de diretório.
O acesso a esta página requer autorização. Podes tentar mudar de diretório.
Este documento explica como as funções nativas que aceitam estruturas de estilo C podem ser chamadas a partir de funções gerenciadas usando P/Invoke. Embora recomendemos que você use os recursos de interoperabilidade C++ em vez de P/Invoke porque P/Invoke fornece pouco relatório de erros em tempo de compilação, não é seguro para tipos e pode ser tedioso de implementar, se a API não gerenciada for empacotada como uma DLL e o código-fonte não estiver disponível, P/Invoke será a única opção. Caso contrário, consulte os seguintes documentos:
Por padrão, as estruturas nativas e gerenciadas são dispostas de forma diferente na memória, portanto, a passagem bem-sucedida de estruturas através do limite gerenciado/não gerenciado requer etapas adicionais para preservar a integridade dos dados.
Este documento explica as etapas necessárias para definir equivalentes gerenciados de estruturas nativas e como as estruturas resultantes podem ser passadas para funções não gerenciadas. Este documento assume que estruturas simples — aquelas que não contêm cadeias de caracteres ou ponteiros — são usadas. Para obter informações sobre interoperabilidade não blittable, consulte Using C++ Interop (Implicit PInvoke). P/Invoke não pode ter tipos que não sejam blittable como valor de retorno. Os tipos Blittable têm a mesma representação em código gerenciado e não gerenciado. Para obter mais informações, consulte Tipos Blittable e Non-Blittable.
Marshaling estruturas simples e blittable através do limite gerenciado/não gerenciado primeiro requer que as versões gerenciadas de cada estrutura nativa sejam definidas. Estas estruturas podem ter qualquer nome jurídico; Não há nenhuma relação entre a versão nativa e gerenciada das duas estruturas além de seu layout de dados. Portanto, é vital que a versão gerenciada contenha campos do mesmo tamanho e na mesma ordem da versão nativa. (Não há nenhum mecanismo para garantir que as versões gerenciada e nativa da estrutura sejam equivalentes, portanto, as incompatibilidades não se tornarão aparentes até o tempo de execução. É responsabilidade do programador garantir que as duas estruturas tenham o mesmo layout de dados.)
Como os membros das estruturas gerenciadas às vezes são reorganizados para fins de desempenho, é necessário usar o StructLayoutAttribute atributo para indicar que a estrutura está disposta sequencialmente. Também é uma boa ideia definir explicitamente a configuração de empacotamento da estrutura para ser a mesma usada pela estrutura nativa. (Embora por padrão, o Visual C++ usa um empacotamento de estrutura de 8 bytes para ambos os códigos gerenciados.)
Em seguida, use DllImportAttribute para declarar pontos de entrada que correspondem a quaisquer funções não gerenciadas que aceitam a estrutura, mas use a versão gerenciada da estrutura nas assinaturas de função, que é um ponto discutível se você usar o mesmo nome para ambas as versões da estrutura.
Agora, o código gerenciado pode passar a versão gerenciada da estrutura para as funções não gerenciadas como se elas fossem realmente funções gerenciadas. Essas estruturas podem ser passadas por valor ou por referência, como demonstrado no exemplo a seguir.
Módulos não gerenciados e gerenciados
O código a seguir consiste em um módulo não gerenciado e um módulo gerenciado. O módulo não gerenciado é uma DLL que define uma estrutura chamada Location e uma função chamada GetDistance que aceita duas instâncias da estrutura Location. O segundo módulo é um aplicativo de linha de comando gerenciado que importa a função GetDistance, mas a define em termos de um equivalente gerenciado da estrutura Location, MLocation. Na prática, o mesmo nome seria provavelmente usado para ambas as versões da estrutura; no entanto, um nome diferente é usado aqui para demonstrar que o protótipo DllImport é definido em termos da versão gerenciada.
Observe que nenhuma parte da DLL é exposta ao código gerenciado usando a diretiva #include tradicional. Na verdade, a DLL é acessada apenas em tempo de execução, portanto, problemas com funções importadas com DllImport não serão detetados em tempo de compilação.
Exemplo: módulo DLL não gerenciado
// TraditionalDll3.cpp
// compile with: /LD /EHsc
#include <iostream>
#include <stdio.h>
#include <math.h>
#define TRADITIONALDLL_EXPORTS
#ifdef TRADITIONALDLL_EXPORTS
#define TRADITIONALDLL_API __declspec(dllexport)
#else
#define TRADITIONALDLL_API __declspec(dllimport)
#endif
#pragma pack(push, 8)
struct Location {
int x;
int y;
};
#pragma pack(pop)
extern "C" {
TRADITIONALDLL_API double GetDistance(Location, Location);
TRADITIONALDLL_API void InitLocation(Location*);
}
double GetDistance(Location loc1, Location loc2) {
printf_s("[unmanaged] loc1(%d,%d)", loc1.x, loc1.y);
printf_s(" loc2(%d,%d)\n", loc2.x, loc2.y);
double h = loc1.x - loc2.x;
double v = loc1.y = loc2.y;
double dist = sqrt( pow(h,2) + pow(v,2) );
return dist;
}
void InitLocation(Location* lp) {
printf_s("[unmanaged] Initializing location...\n");
lp->x = 50;
lp->y = 50;
}
Exemplo: módulo de aplicativo de linha de comando gerenciado
// MarshalStruct_pi.cpp
// compile with: /clr
using namespace System;
using namespace System::Runtime::InteropServices;
[StructLayout(LayoutKind::Sequential, Pack=8)]
value struct MLocation {
int x;
int y;
};
value struct TraditionalDLL {
[DllImport("TraditionalDLL3.dll")]
static public double GetDistance(MLocation, MLocation);
[DllImport("TraditionalDLL3.dll")]
static public double InitLocation(MLocation*);
};
int main() {
MLocation loc1;
loc1.x = 0;
loc1.y = 0;
MLocation loc2;
loc2.x = 100;
loc2.y = 100;
double dist = TraditionalDLL::GetDistance(loc1, loc2);
Console::WriteLine("[managed] distance = {0}", dist);
MLocation loc3;
TraditionalDLL::InitLocation(&loc3);
Console::WriteLine("[managed] x={0} y={1}", loc3.x, loc3.y);
}
[unmanaged] loc1(0,0) loc2(100,100)
[managed] distance = 141.42135623731
[unmanaged] Initializing location...
[managed] x=50 y=50