Patrice,
I think your have misunderstood me (or i did you),
>From what you wrote i gather that you are talking about using .Net dlls in
native applications, which is not the case here, i need it the other way
around.
Our server is a .Net application and so we'd either have to somehow get the
Uplink/applink to recognize a method in the .Net assembly (i understood that
it cannot be in an adjacent dll) OR to completely eliminate the Applink
usage.
If i misunderstood please correct me :)
Amit Ben Shahar
VP R&D
ISQ Technologies
(+972) 545-592-934
a...@isqgroup.net
www.isqgroup.net
2010/4/24 Patrice Guérin <guer...@magic.fr>
> 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> 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
>
>
