Usando DLLs mistos a partir de / clr: projectos puros

Question

Eu estou construindo um projeto juntamente com uma DLL.

A DLL deve suportar o código nativo para que eu declarou-o como um / clr. Meu projeto era initialy também num projecto / clr e estava tudo bem. No entanto, eu gostaria de incluir alguns testes NUnit então eu tive que mudar meu projeto principal de / clr para / clr:. Puro

Tudo ainda compila mas qualquer chamada DLL gera um erro de tempo de execução. Quando eu voltar para / clr tudo está ok

Na minha DLL, funções exportadas são declarados como segue:

#define DllExport   __declspec( dllexport )
DllExport bool DisplayScan(bool bShow, bool bAllPasses) { }

Também fiz um arquivo .def contendo os nomes verdadeiros de todas as funções exportadas

LIBRARY "Controller"
EXPORTS
DisplayScan

Do meu projeto principal minhas importações são declarados como segue:

#define _DllImport [DllImport("Controller.dll", CallingConvention = CallingConvention::Cdecl)] static
_DllImport bool DisplayScan(bool bShow, bool bAllPasses)

Alguém já encontrou um tal problema?

Answer 1

Ok tudo está funcionando agora

Na verdade, ele tem trabalhado desde o início.

Moral: não tente lançar um char * em um std :: string

O estranho: its ok in / clr até retornar da função. Ele trava imediatamente in / clr: puro

Answer 2

Basicamente, você está fazendo algo que não é suportado; / Clr: puro e exportações DLL nativa. Como citou este artigo MSDN "assembléias puros não podem exportar funções que são pode ser chamado de funções nativas, pois os pontos de entrada em uma pura montagem usar o __clrcall convenção de chamada. "

Eu não tenho certeza da melhor solução. No entanto, com um pouco de experimentação, você provavelmente poderia tirar proveito da __clrcall convenção de chamada com a opção / clr. Aqui está um link , que pode ser útil. Desde que eu possa reunir você deve ser capaz de exportar as classes gerenciadas e consumi-los a partir de um conjunto tal como o seu projeto de teste NUnit conseguiu conseguiu, mas manter suas exportações não gerenciados lá com diferentes assinaturas de método. Tenha em mente que, logo que você expor qualquer classe .net via uma exportação, será necessário usar a convenção de chamada __clrcall.

Answer 3

Vantagens de / clr: puro

Melhor Performance: Porque os conjuntos puros conter apenas MSIL, não há funções nativas e, portanto, não gerenciados / transições não gerenciados são necessários. (chamadas de função feitas através P / Invoke são uma exceção a esta regra.)

Consciência AppDomain: funções gerenciados e tipos de dados CLR existir dentro de domínios de aplicação, o que afeta a sua visibilidade e acessibilidade. montagens puros são de domínio-aware (__declspec (appdomain) está implícito para cada tipo) para acessar seus tipos e funcionalidades de outros componentes do NET é mais fácil e mais seguro. Como resultado, os conjuntos puros interagir mais facilmente com outros componentes do NET do que conjuntos mistos.

carregamento não-rígido: montagens puros podem ser carregados na memória e até mesmo transmitido. Isto é essencial para a utilização de conjuntos .NET como procedimentos armazenados. Isso é diferente de assembléias mistas, que devido a uma dependência sobre os mecanismos de carregamento do Windows, devem existir no disco, a fim de executar.

Reflexão: Não é possível refletir sobre executáveis ??mistos, enquanto os conjuntos puros fornecer suporte reflexão total. Para mais informações, consulte Reflexão (C ++ / CLI).

Anfitrião Controlabilidade:. Porque os conjuntos puros conter apenas MSIL, eles se comportam de forma mais previsível e flexível do que os conjuntos mistos quando usado em aplicações que hospedam o CLR e modificar seu comportamento padrão

Limitações de / clr: puro

Esta seção abrange as funcionalidades não suportadas atualmente pelo / clr:. Puro

montagens puros podem não ser chamado por funções não gerenciadas. Portanto conjuntos puros não podem implementar interfaces COM ou expor as chamadas de retorno nativas. montagens puros não podem exportar funções via __declspec (dllexport) ou arquivos .def. Além disso, as funções declaradas com a convenção __clrcall não podem ser importados via __declspec (dllimport). Funções em um módulo nativo pode ser chamado a partir de um conjunto puro, mas conjuntos puros não podem expor funções nativas-exigível, de modo expor a funcionalidade de um conjunto puro tem de ser feito por meio de funções de gestão de um conjunto misto. Consulte Como: Migrar para / clr:. Puro (C ++ / CLI) para mais informações

bibliotecas

ATL e MFC não são suportados pela compilação modo puro no Visual C ++.

.netmodules puros não são aceitos como entrada para vinculador do Visual C ++. No entanto, ficheiros.OBJ puros são aceites pelo vinculador, e obj arquivos contêm um super conjunto de informações contidas netmodules. Veja .netmodule arquivos como vinculador de entrada para obter mais informações.

suporte Compiler COM (# Import) não é suportado, pois isso iria introduzir instruções não gerenciados para o conjunto puro.

flutuação opções de ponto para o alinhamento e a excepção de manipulação não são ajustáveis ??para conjuntos puros. Como resultado, __declspec (align) não pode ser usado. Isso torna alguns arquivos de cabeçalho, como fpieee.h, incompatíveis com / clr:. Puro

A função GetLastError na PSDK pode dar comportamento indefinido ao compilar com / clr:. Puro

Answer 4

seu problema está chamando conventionCallingConvention = CallingConvention :: Cdecl ... definir a sua função assim ou utilização stdcall ou clrcall, clecl é por puro C

ou problema é aqui: definir essa função extern não estática