BCrypt Functions

[amin1best]

Hi,
How can I use BCryptAddContextFunction, BCryptRemoveContextFunction functions with CsWin32?

https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptaddcontextfunction
https://docs.microsoft.com/en-us/windows/win32/api/bcrypt/nf-bcrypt-bcryptremovecontextfunction

[AArnott]

Per our readme file, just add those method names to the NativeMethods.txt file. Then consume them using similar code as you would in C++.

As far as sample usage of these functions specifically, CsWin32 isn't an appropriate forum to get Win32 API usage help.

[amin1best]

Thanks, @AArnott
I added BCryptEnumContextFunctions in NativeMethods.txt and used Windows.Win32.Security.Cryptography Namespace but did not recognize PInvoke.BCryptEnumContextFunctions. I thought there was something I did not do but I closed VSCode and reopened it, the problem was solved. I think there is a problem with my VSCode because every time I add a function to NativeMethods.txt, I have to close and reopen VSCode once for PInvoke to recognize it.
I wrote the following code:

using System;
using Windows.Win32;
using Windows.Win32.Security.Cryptography;
using Windows.Win32.Foundation;

namespace testnet
{
    class Program
    {
        static void Main(string[] args)
        {
            unsafe
            {
                uint pcbBuffer = 0;
                CRYPT_CONTEXT_FUNCTIONS* ppBuffer = null;

                NTSTATUS result = PInvoke.BCryptEnumContextFunctions(BCRYPT_TABLE.CRYPT_LOCAL, "SSL", BCRYPT_INTERFACE.NCRYPT_SCHANNEL_INTERFACE, ref pcbBuffer, ref ppBuffer);
                Console.WriteLine(ppBuffer->cFunctions);
            }
        }
    }
}

Is there a solution to remove unsafe?
I used CRYPT_CONTEXT_FUNCTIONS parameter in DllImport as IntPtr and then read ppBuffer value using Marshal.PtrToStructure, but now in PInvoke.BCryptEnumContextFunctions, the ppBuffer parameter is passed as CRYPT_CONTEXT_FUNCTIONS* Pointer.

[AArnott]

Some functions CsWin32 generates include a "friendly overload" that removes some pointers, but achieving "safe" code is not a goal, so if you don't see an overload that doesn't require unsafe, it's unlikely there will be one.

Interop is never "safe". And avoiding the C# unsafe keyword by using IntPtr and the Marshal class usually serves to remove type safety, obfuscate interop code, and can make memory leaks easier than using pointers (ironically, perhaps).