If it is another Windows API you wanna call, then there is absolutely no reason to not directly call it by its exported name using Interop.Call.
If it is not a Windows API, but some internal non-exported procedure in the process then you can (ab)use the Windows API
CallWindowProc.
Although not 'officially' supported, it is the function which is (ab)used to call procedures by address.
If you examine its parameters you'll notice that it actually does exactly that; calling a procedure by address. This because a window handle has in fact always the same value as the address of the
WinProc procedure for that window (the procedure which is responsible for handling the recieved Windows Messages etc). So, the API does nothing more than instructing the computer to call the procedure at address
hWnd. The rest of the 4 parameters are simply input parameters for that procedure.
However, there are some big risks involved in (ab)using that. For starters you need to know exactly what the procedure you're calling does and where it gets its parameters from, how they are handled, etc. You also need to know if it is safe to call that procedure just out of the blue. This is by no means a straithforward thing to do and requires reverse engineering to get that knowledge. Even getting one small thing wrong might BSOD Windows.
Also note that this API is actually mostly (ab)used to call injected assembler code (so yes, you can use this API to run assembler code from within _any_ language which allows you to call this Windows API, like for example Plus! scripting).
/ 
