library and pure

  • Thread starter Thread starter dragonslayer008
  • Start date Start date
D

dragonslayer008

I am building a control library in C++/CLI. My project links with a
native library and am getting an error that the library cannot work
with pure:

dxerr.lib(dxerr.obj) : fatal error LNK1313: ijw/native module
detected; cannot link with pure modules

I am fine switching to CLR mode, but I have a question. If I build
the control library DLL in CLR mode, will it still integrate
seamlessly into C#/VB projects? Or will I have to change compiler
switches in the C#/VB projects as well?
 
I am building a control library in C++/CLI. My project links with a
native library and am getting an error that the library cannot work
with pure:

dxerr.lib(dxerr.obj) : fatal error LNK1313: ijw/native module
detected; cannot link with pure modules

I am fine switching to CLR mode, but I have a question. If I build
the control library DLL in CLR mode, will it still integrate
seamlessly into C#/VB projects? Or will I have to change compiler
switches in the C#/VB projects as well?
Click to expand...


It will work just fine. However, if you want to debug through the C++/CLI
code, you'll have to set "Enable native debugging" in the main application
(probably C#/VB).
 
I am building a control library in C++/CLI. My project links with a
native library and am getting an error that the library cannot work
with pure:

dxerr.lib(dxerr.obj) : fatal error LNK1313: ijw/native module
detected; cannot link with pure modules

I am fine switching to CLR mode, but I have a question. If I build
the control library DLL in CLR mode, will it still integrate
seamlessly into C#/VB projects? Or will I have to change compiler
switches in the C#/VB projects as well?
Click to expand...

As Ben already replied, it'll work fine with C#/VB - the language of the
host application is not an issue.

The important difference between /clr, /clr:safe and /clr:pure is the amount
of trust required to run the resulting program. /clr:safe requires the
least trust, as the resulting assembly is pure and verifiable. /clr:pure
requires more trust because the assembly is not verifiable, and /clr
requires still more because the assembly contains mixed managed/native code.

-cd
 
Carl Daniel said:
As Ben already replied, it'll work fine with C#/VB - the language of the
host application is not an issue.

The important difference between /clr, /clr:safe and /clr:pure is the
amount of trust required to run the resulting program. /clr:safe requires
the least trust, as the resulting assembly is pure and verifiable.
/clr:pure requires more trust because the assembly is not verifiable, and
/clr requires still more because the assembly contains mixed
managed/native code.
Click to expand...

I think /clr and /clr:pure are equivalent trust-wise: both require
FullTrust. But /clr:pure is processor-independent, that is to say that it
can be JITted to 32-bit or 64-bit as needed, while mixed-mode /clr
assemblies have bitness determined by the native code.

Also /clr:pure executables can be loaded as libraries, while mixed-mode
executables have the relocation segments stripped and can only be the main
process.
 
Back
Top