Hi Shubhendu,
> I searched through and I have a clue that we need to include librfc32u.dll file with librfc32.dll file.
This is not completely correct. librfc32u does not have to be used in addition to librfc32, but instead of it.
So what you need to do, is to replace the librfc32.dll with librfc32u.dll. However, this is not so simple: in the non-Unicode library all input/output data is handled as 1-byte char types, while in the "u-version" it is handled as 2-byte wchar_t type. Also the layout of the structures used by the ABAP function modules needs to be changed. So it means code changes in a few places and then re-compiling the application.
And now comes the really bad news: both, librfc32.dll as well as librfc32u.dll have reached their end-of-life 2 months ago... See Support for Classic RFC Library Ends March 2016
So instead of replacing librfc32.dll with librfc32u.dll, you would need to replace it with the "new" RFC library sapnwrfc.dll. This also needs a few code changes and re-compilation of the application.
So much as a short introduction to the topic... Now I want to point out a few things, which are not quite clear to me yet:
- First of all, a Unicode system is also capable of communicating in non-Unicode! So actually your old ASP applications should work fine just as before the conversion to Unicode! What errors do you get? Can you activate RFC trace to see what's going wrong?
- I can't believe that an ASP application is communicating directly with the librfc32.dll. Is it not rather the case, that the ASP application is using the old .NET Connector 2.0 (which is using librfc32.dll internally)? In that case it would perhaps be best to convert your ASP application to the new .NET Connector 3.0, if you really want to Unicode-enable it!
Best Regards, Ulrich