Hello Amit,
Maybe you can explore the "IJW" way...
I use Visual C++ 6 to build my aWin32 pplications and I had to use some
.NET Crypto functions such as RSA to communicate with a customer.
I've used Visual C++ 2005 Express, in which I add the Win32 environment
(from a platform SDK. Express don't have Win32 environment by
default...) to compile
the .NET dll and use it from a win32 dll.
The trick is to use #pragma managed / #pragma unmanaged as appropriate
cryptodotnet.h : the include file for win32/.NET
#ifndef CRYPTDOTNET_EXPORT
#define CRYPTDOTNET_EXPORT __declspec( dllimport )
#endif
#define CRYPTDOTNET_VERSION "1.0.0"
#define CRYPTDOTNET_DATE "20100228"
class CRYPTDOTNET_EXPORT CryptDotNet
{
public:
CryptDotNet() {};
virtual ~CryptDotNet() {};
int RSAEncrypt( const char* XmlPublicKey, const unsigned char* Data,
const int DataLength, char* Base64EncryptBuffer, int* Base64EncryptBufferLength
);
...
};
cryptodotnet.cpp : compiled with VC++2005
#define CRYPTDOTNET_EXPORT __declspec(dllexport)
#pragma unmanaged
#include "cryptdotnet.h"
#include <memory.h>
#include <string.h>
#pragma managed
class CryptDotNetManaged
{
public:
CryptDotNetManaged() {};
~CryptDotNetManaged() {};
int RSAEncrypt( const char* XmlPublicKey, const unsigned char* Data,
const int DataLength, char* Base64EncryptBuffer, int* Base64EncryptBufferLength
);
};
//Unmanaged interface
int CryptDotNet::RSAEncrypt( const char* XmlPublicKey, const unsigned char*
Data, const int DataLength, char* Base64EncryptBuffer, int*
Base64EncryptBufferLength )
//
{
CryptDotNetManaged c;
return c.RSAEncrypt( XmlPublicKey, Data, DataLength,
Base64EncryptBuffer, Base64EncryptBufferLength );
}
// Managed part
#pragma managed
using namespace System;
...
int CryptDotNetManaged::RSAEncrypt( .... )
{ ... };
This works very well.
In your case, maybe the applink.c should be considered as unmanaged code.
some references for inspiration...
http://ondotnet.com/pub/a/dotnet/2003/01/13/intromcpp.html
http://www.techheadbrothers.com/Articles.aspx/integrez-code-cplusplus-natif-applications-dotnet-page-1
(sorry... in french...)
and finally the thread "Win32 OPENSSL_USE_APPLINK usage" in OpenSSL-dev
Hope this helps.
Patrice.
Amit Ben Shahar a écrit :
On Fri, Apr 23, 2010 at 21:35, James Mansion
<ja...@mansionfamily.plus.com <mailto:ja...@mansionfamily.plus.com>>
wrote:
Amit Ben Shahar wrote:
One of the crucial ingredients is ssl using OpenSsl. but we
are encountering a problem with the 'no OPENSSL_Applink' error.
as this is a .Net project, there is no way (i can think of) to
compile with the applink.c file.
1) Why is that crucial? Microsoft provide crypto support on
Windows, albeit with a different interface. What's wrong with
System.Net.Security.SslStream?
The .Net.Security.SslStream is not working in asynchronous calls,
meaning we'd have to implement it in a thread-per-connection paradigm,
which is obviously not an option.
2) Why can't you 'compile with the applink.c file'? You need a
talk to it through p/invoke - you may need to write another glue
DLL to do this. If you can locate an OpenSSL implementation that
has been wrapped as a free-threaded COM service, you might find
things easier if you don't know how to write such glue. You could
try looking in Mono's runtime, too, which I suspect delegates to
OpenSsl (tho I haven't checked).
As far as i understood it, openSsl looks for the applink
implementation in the actual application and not in dlls, but i could
have misread that, anyhow i'm not sure i would know how to do that,
can you maybe directly to such an implmentation (free-threaded COM) ?
- in the meantime i'll try checking in Mono, though i've never ever
looked at it yet. maybe i'll get lucky ;)
thanks
