Florian,

Ahh, true, you are completely correct.

Thinking more closely to what you want to do, I realize you might not need
to actually pin the delegate at all; just keep a reference to it alive so
that it is not garbage collected (it actually does *not* matter that it
moves around in memory, as that won't affect the call to it from unmanaged
code in this particular case).

I looked around to verify this, and found what I was looking for:
http://blogs.msdn.com/cbrumme/archive/2003/05/06/51385.aspx

Here, Chris Brumme explains in detail:

"Along the same lines, managed Delegates can be marshaled to unmanaged code,
where they are exposed as unmanaged function pointers.  Calls on those
pointers will perform an unmanaged to managed transition; a change in
calling convention; entry into the correct AppDomain; and any necessary
argument marshaling.  Clearly the unmanaged function pointer must refer to a
fixed address.  It would be a disaster if the GC were relocating that!  This
leads many applications to create a pinning handle for the delegate.  This
is completely unnecessary.  The unmanaged function pointer actually refers
to a native code stub that we dynamically generate to perform the transition
& marshaling.  This stub exists in fixed memory outside of the GC heap.

However, the application is responsible for somehow extending the lifetime
of the delegate until no more calls will occur from unmanaged code.  The
lifetime of the native code stub is directly related to the lifetime of the
delegate.  Once the delegate is collected, subsequent calls via the
unmanaged function pointer will crash or otherwise corrupt the process.  In
our recent release, we added a Customer Debug Probe which allows you to
cleanly detect this – all too common – bug in your code.  If you haven’t
started using Customer Debug Probes during development, please take a look!"

Hope this helps!

I just wrote this little C# App:

namespace PinTestApp
{
   public delegate void TestDelegate();

   public partial class Form1 : Form
   {
       public Form1()
       {
           InitializeComponent();

           TestDelegate test = new TestDelegate(Test);
           GCHandle handle = GCHandle.Alloc(test, GCHandleType.Pinned);
           handle.Free();
       }

       private void Test()
       {
       }
   }
}

As soon as the debugger hits the line 'GCHandle handle =
GCHandle.Alloc(test, GCHandleType.Pinned);' I get the same
ArgumentException.
What other options do I have if GCHandle doesn't work?

I have tested the callback for SHBrowseForFolder, it worked .
BFFCALLBACK is defined as a native callback type for the SHBrowseForFolder
function.

delegate int BrowseCallBackProcDelegate(
unsigned/*HWND*/ hwnd, unsigned int/*UINT*/ uMsg
, unsigned/*LPARAM*/ lParam, unsigned/*LPARAM*/ lpData);

[STAThreadAttribute]
int main(array<System::String ^> ^args)
{

Form1^ pForm1=gcnew Form1();
// Enabling Windows XP visual effects before any controls are created
Application::EnableVisualStyles();

BrowseCallBackProcDelegate^ BCBD =
 gcnew BrowseCallBackProcDelegate(Form1::BrowseForFileCallBackProc);

pin_ptr<BrowseCallBackProcDelegate^> pBCBD= &BCBD;

IntPtr delegatePointer =
 Marshal::GetFunctionPointerForDelegate(BCBD);

pForm1->m_pbi->lpfn=static_cast<BFFCALLBACK>(delegatePointer.ToPointer());

// Create the main window and run it
Application::Run();
return 0;
}

(HOOKPROC)(Marshal::GetFunctionPointerForDelegate(innerEventHandler).ToPoint