I see. But it still results in a linker error when compiling managed C++ code. I don't believe this is a question of the library being .NET compliant but rather that something is still linking to the DES code even though it is no longer exported in the DLL. Perhaps the .NET linker is a bit more strict when it comes to ensuring linker symbols are properly exported?
I don't have this problem anymore, though, as I've finished my previous managed code project. However, the HexEncoder issue has still not been solved (http://www.mail-archive.com/[email protected]/msg02738.html).
From: [EMAIL PROTECTED]
To: [email protected]
Subject: DES in FIPS DLL (Was: Unresolved External Symbol)
Date: Wed, 13 Sep 2006 13:38:27 +0800
Single DES is no longer FIPS compliant, that's why it was removed from the DLL. Sorry about not clarifying this earlier.----- Original Message -----From: Søren DreijerSent: Monday, May 01, 2006 5:31 AMSubject: Unresolved External SymbolUpdate:
I noticed that the Crypto::DES::Base class wasn't exported in the DLL build. I'm not sure if that is a bug or if it's done on purpose to comply with the FIPS specification, but it *did* cause the linker to fail.
Having added CRYPTOPP_DLL to the class name fixed the unresolved external symbol.
Express yourself instantly with MSN Messenger! MSN Messenger
Get the new Windows Live Messenger! Try it!
