Would anyone happen to know how i can eliminate the requirement of the
applink implementation? why would we actually need it?
Amit Ben Shahar
On Sat, Apr 24, 2010 at 13:25, Amit Ben Shahar <amit.b...@gmail.com> wrote:
> 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
>>
>>
>
